[Gluster-infra] Configuration management, part 2

[Michael Scherer]

Hi,

so as the feedback was not negative for my proposal, I would like to go
forward and propose something more concrete to discuss.

So since there was not much feedback on the tool used and since Justin
said "no ruby if possible", i would propose to go with Ansible.

It is simple enough to deploy ( no agent ), which make it suitable for
the variety of platform we have in the infra, and combining the task of
configuration management and server orchestration, it permit to have 1
system instead of 2 to deploy and learn. 

It is quite simple to understand ( more than cfengine IMHO ), and this
is not Ruby ( so justin will be happy ). I am quite familiar with the
tool, and while I tried hard to take "what I prefer", no one express any
preference anyway :)

it is also used more and more inside RH, and on Fedora.

Ansible use root ssh to manage servers, so that requires we have some
authentication setup for that. Since that's the easiest, I guess we can
just set a key for the access, and make sure the key is protected
"enough" ( I would be in favor of rotating it quite often, restrict it
by IP and would use a TPM if we could, but there is no way to do that
with our rackspace infra for the foreseeable future.

This also mean that the access to the server would be restricted and
that we want to audit as much as we can. 

So I propose :
- have a git repository, and automated deployment/run of ansible on
commit + cron ( for making sure servers are compliant ). This would run
from a special user on the bastion, who have access to the right key. It
would be nice to have that user as restricted as possible

- have proper security on the bastion. IE, firewall, selinux as
enforcing, potentially even user confined.

- have a strict policy on who can access it, and making sure this
requires strong authentication. We can either do it with regular 2
factor auth, or just password + ssh key, or sudo + ssh keys for access.

- make sure the server do nothing more than this


There is lots of others way to setup ansible, but I do not think they
would be suitable. 

For example, we can have the ansible run to not be automated, but
requires a password. This would solve my concern regarding ssh keys, but
I do see that as tedious, and would likely bring more roadblock than it
can help.

We can also have ansible-pull, which take the git repository on each
server and apply it locally. This also solve the problem of ssh keys
protection, but this one would cause issues since this only solve half
of the problem ( configuration management, not one off task
administration ), and would mean that every server has access to the
password ansible have access to. 

Any comments ?


-- 
Michael Scherer
Open Source and Standards, Sysadmin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://www.gluster.org/pipermail/gluster-infra/attachments/20140826/bc44278e/attachment.sig>