From the FAQ section: "If your central server is taken over (or even logged into by a malicious employee), provided you were using SSH-agent and encrypted keys (and/or sudo with a password), your keys are still locked and no one can take control of your nodes"
It means if I have setup passwordless login to all my nodes the user can take control over all the nodes, if he has control of the central server. Right? If I want to automate the management (Example: Software updates) the system will need a privileged user rights, how can we automate but still secure the nodes?
If using sudo passwords, getting your keys will give them login but
not admin privileges (unless you put your keys in root's
authorized_keys file). They also need to know the password on each
node.
if you want automated system updates it is easier to cron at the node,
ansible-pull can work this way. Then central server won't need
unprotected key and passwordless sudo or root login.
What this means is by using SSH keys with passwords (not sudo with a
password, we mean about encrypted SSH keys) gaining root access to the
central build server in any way doesn't give you any ability to change
what is happening on the nodes. You still have to use ssh-agent and
enter your password, or otherwise supply your password, in order to
make the key useful, and you are still limited by the node's decision
to let you in.
Sudo is of course a layer beyond that, but not the primary protection system.
This is not true of other config management systems that are based on
PKI systems.
sorry I should have been more explicit, I wasn't trying to explain the FAQ.
Just to address what I inferred was a misunderstanding and to give him
a way to attain (again, what I inferred) was his purpose (unattended
ansible driven updates).
On my way building OpenStack Proof-of-Concept setup with Ansible. I really
like Ansible.
Excellent, I'm doing OpenStack things at work now (not with Ansible --
but that's ok), so I would be very interested in seeing if you get to
a point where you can publish your playbooks. I'd much rather grok
what is in a good OpenStack installation from reading a series of
Ansible playbooks than looking at devstack shell scripts.
Lorin Hochenstein also has some earlier work done with Vagrant here ( https://github.com/lorin/openstack-ansible
) -- I'd really like to see a multi-server deployment, and also
including Quantum. I would assume the Vagrant pieces can be skipped
over for those not using Vagrant.
If you do look at the OpenStack Ansible scripts I wrote, note that they were written for Essex, not Folsom, and so they don’t include things like Quantum and Cinder. (They do, however, support multi-node, if you run under Vagrant it will actually launch two VMs, a cloud controller and a compute node).
Also, if you run into any problems with the official OpenStack documentation as you go, please submit a documentation bug at https://bugs.launchpad.net/openstack-manuals/+filebug (I’m a member of the OpenStack doc team).
Some day, I’d like to write some OpenStack modules for Ansible to make it easier to do things like manage users, services, and projects/tenants in keystone. One of those days…
