Awx: Kerberos Support in Containers

[MrBones757]

ISSUE TYPE

• Feature Idea

SUMMARY

Kerberos binaries and configuration don't seem to be currently supported out of the box with AWX.
The feature idea here would be to:

• add these binaries to the docker containers
• add support to the kubernetes installer to provision these configs into the container and run necessary commands to init if parameters for this have been provided.

I have read though comments here: https://github.com/ansible/awx/issues/735
which was suggesting root / privileged access was required. I have not fully validated this yet but i believe data in the second link would allow this to be resolved.

This would utelise the following:

• https://docs.ansible.com/ansible-tower/latest/html/administration/kerberos_auth.html
• https://blog.tomecek.net/post/kerberos-in-a-container/

Any additional feedback and requirements appreciated.
Cheers!

[wenottingham]

What are you asking for? Just the ability for WinRM-initiatied kinit to run?

[MrBones757]

The implementation here would be:

• add required binaries to containers for kerberos operation
• add required configuration files & scripts to kube deployment scripts (config maps)
• add parameters to inventory file for credentials passthough

with the goal of:
Allowing users to conditionally enable kerberos support as described in the above tower documentation. This includes running the kinit in each container on container startup to obtain required keberos context / tickets.

to allow:
awx containers to use kerberos auth via winRM rather than basic auth

does this provide the required context? happy to provide additional information around usecase.

[MrBones757]

Update: I have implemented and tested a proof of concept.
the solution is based off the 10.0.0 release tag, but there are some changes coming on devel that will make this much better implementation wise (and alittle less hacky).
Would be happy to submit as a PR if you were curious about implementation

[MrBones757]

@wenottingham Does this information provide the detail you were after?
Cheers :)

[wenottingham]

This includes running the kinit in each container on container startup to obtain required keberos context / tickets.

This is not the way I'd prefer to support this, unless I'm misunderstanding you. For things like WinRM, there is per-playbook kinit, and you generally want to be able to authenticate, depending on what you're running, as multiple principals for different pieces of automation.

[MrBones757]

unless i have misunderstood: https://docs.ansible.com/ansible-tower/latest/html/administration/kerberos_auth.html

What i have implemented is the following:
the kinit has 'domain joined' the containers such that they are registered against a kerberos auth provider (active directory - they have a ticket), from there you then use machine credentials to actually complete the auth against a target machine.

This means the actual principal or auth credential used against the server is the machine credential you specify at a job template level, where as the kinit your perform on container startup is allowing that kerberos relationship to succeed / function in the first place against the auth provider (AD) to verify the user's (machine credential) permissions on the target.

This would be similar to domain joining a windows machine and then having other 'domain users' log into this system. (I recognise that the two processes are very different, but i'm attempting to explain how i've understood this documentation / concept)

The PoC i have implemented uses a service account with limited domain user permissions do run the initial kinit in each container, and then my personal domain user account as the machine credential which has permissions n my target machine. This seems to function as i have explained above, unless there is some behaviour that i have not accounted for allowing this to work.

[wenottingham]

CC'ing @jborean93 , but as I understand it, the joining of the machine isn't necessarily needed, as long as the kerberos configuration is there.

[jborean93]

Yep no need to join it to the domain, even then you may not even need the config if DNS is set up correctly. Your main requirements are

• The krb5 library is installed with the relevant header files
• The relevant Python library that talks to gssapi/krb5 is installed
• DNS is set up to resolve FQDN of hosts in the realm/domain you want to talk to
• Optional but still best to be set - Set up /etc/krb5.conf to specify the realm and KDC in that realm as well as any other options you want set

For my dev machine I just have a very minimal krb5.conf that specifies the realm, the KDC in the realm and my host has DNS set up to resolve any hosts that end with .<domain>.<realm> to the DC.

[MrBones757]

Oh thanks for that info - thanks for clearing up that misunderstanding :)

so in that case then all we would really need to add is the krb5.conf file template to the kubernetes scripts to facilitate this, and an override for the keytab location to avoid needing root permissions. i will make this change and remove this section of the code from my test instance and see how i go!

would adding this as a config option to the installer scripts be desirable from your perspectives?

[bobby0724]

Basically what we need is pywinrm[kerberos]

in order to install this module we need the kerberos development libraries in the container is this posible
currently using ansible with credssp is not a good idea we prefer to use kerberos