Ansible is a workflow engine. I use it to do work on my behalf.
FreeIPA is an identity management system. It allows me to manage the identities of users in my organization
How do I get the two things to work together? The short answer is that it is trivial to do using Ansible Engine. It is harder to do using Ansible tower.
Edit: Second part is here. Third part is coming.
Table of contents
Lets start with engine. Lets say that I want to execute a playbook on a remote system. Both my local and remote systems are FreeIPA clients. Thus, I can use Kerberos to authenticate when I ssh in to the remote system. This same mechanism is reused by Ansible when I connect to the system. The following two commands are roughly comparable
scp myfile.txt ayoung@hostname:
ansible --user ayoung hostname -m copy -a / "src=myfile.txt dest=/home/ayoung"
Ignoring all the extra work that the copy module does, checking hashes etc.
Under the covers, the ssh layer checks the various authentication mechanism available to communicate with the remote machine. If I have run kinit (successfully) prior to executing the scp command, it will try the Kerberos credentials (via GSSAPI, don’t get me started on the acronym soup) to authenticate to the remote system.
This is all well and good if I am running the playbook interactively. But, what if I want to kick off the playbook from an automated system, like cron?
The most common way that people use ssh is using asymmetric keys with no certificated. On a Linux system, these keys are kept in ~/.ssh. If I am using rsa, then the private key is kept in ~/.ssh/id_rsa. I can use a passphrase to protect this file. If I want to script using that key, I need to remove the passphrase, or I need to store the passphrase in a file that automates submitting it. While there are numerous ways to handle this, a very common pattern is to have a second set of credentials, stored in a second file, and a configuration option that says to use them. For example, I have a directory ~/keys that contains an id_rsa file. I can use it with ssh like this:
ssh firstname.lastname@example.org -i ~/keys/id_rsa
And with Ansible:
ansible -i inventory.py ayoung_resources --key-file ~/keys/id_rsa -u cloud-user -m ping
Ansible lacks knowledge of Kerberos. There is no way to say “kinit blah” prior to the playbook. While you can add this to a script, you are now providing a wrapper around Ansible.
Automating via Kerberos
Kerberos has a different way to automate credentials: You can use a keytab ( a file with symmetric keys stored in it) to get a Ticket Granting Ticket (TGT) and you can place that TGT in a special directory: /var/kerberos/krb5/user/<uid>
I wrote this up a few years back: https://adam.younglogic.com/2015/05/auto-kerberos-authn/
Lets take this a little bit further. Lets say that I don’t want to perform the operation as me. Specifically, I don’t want to create a TGT for my user that has all of my authority in an automated fashion. I want to create some other, limited scope principal (the Kerberos term for users and things that are like users that can do things) and use that.
I’d prefer to create a service principal from my machine. If my machine is testing.demo1.freeipa.org and I create on it a service called ansible, I’ll end up with a principal of:
A user can allocate to this principal a Keytab, an X509 Certificate, or both. These credentials can be used to authenticate with a remote machine.
If I want to allow this service credential to get access to a host that I set up as some specified user, I can put an entry in the file ~/.k5login that will specify what principals are allowed to login. So I add the above principal line and now that principal can log in.
Lets assume, however, that we want to limit what that user can do. Say we want to restrict it only to be able to perform git operations. Instead of ~/.k5login, we would use ~/.k5users. This allows us to put a list of commands on the line. It would look like this:
Now that we can set up delegations for the playbooks to use, we can turn our eyes to Ansible Tower. Today, when a user kicks off a playbook from Tower, they have to reuse a set of credentials stored in Ansible tower. However, that means that any external identity management must be duplicated inside tower.
What if we need to pass through the user that logs in to Tower in order to use that initial users identity for operations? We have a few tools available.
Lets start with the case where the user logs in to the Tower instance using Kerberos. We can make use of a mechanism that goes by the unwieldy name of Service-for-User-to-Proxy, usually reduced to S4U2Proxy. This provides a constrained delegation.
What if a user is capable of logging in via some mechanism that is not Kerberos? There is a second mechanism called Service-for-User-to-Self. This allows a system to convert from, say, a password based mechanism, to a Kerberos ticket.
Simo Sorce wrote these up a few years back.
And the Microsoft RFC that describe the mechanisms in detail
In the case of Ansible Tower, we’d have to specify at the playbook level what user to use when executing the template: The AWX account that runs tower, or the TGT fetched via the S4U* mechanism.
What would it take to extend Tower to do use S4U? Tower can already user Kerberos from the original user:
The Tower web application would then need to be able to perform the S4U transforms. Fortunately, iot is Python cade. The FreeIPA server has to perform these transforms itself, and it would be comparable transforms.
Configuring the S4U mechanisms in FreeIPA is fairly manual process, as documented by https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/ I would suggest using Ansible to automate it.
Kerberos provides a distributed authentication scheme with validation that the user is still active. The is a powerful combination. Ansible should be able to take advantage of the Kerberos support in ssh to greatly streaml;ine the authorization decisions in provisioning and orchestration.
Hi! Thanks for the blog! Iâ€™m preparing a Ansible/FreeIPA deployment in a test environment.
In the IPA documentation, the sssd daemon and ipa command are used to manage ssh keys centrally along with openssh, and are installed as part of the client enrollment. All public keys and known hosts are stored in one location.
HBAC host based access control can be used to create rules about which users, hosts, services, and groups can then talk to each other.
Iâ€™m wondering what the role of Kerberos and multiple keytabs would serve if a keytab must be created for each service/host instance. Doesnâ€™t that defeat the purpose of centralizing rules and minimizing management overhead? If Ansible has no knowledge of Kerberos, why get Kerberos involved?
Thank you so much for your articles. Iâ€™m learning so much!