Request for enhancement

As administrator, I want to manage Kerberos identities for my containerized applications in FreeIPA and automate issuing keytabs and access to them for the instances of them on the multiple hosts where they are deployed.

Additional info:

Microsoft has recently proposed a way for Windows hosts to issue domain credentials for containers: https://github.com/kubernetes/kubernetes/issues/62038. This approach is supposed to give containerized applications a way to securely obtain domain credentials for the purpose of authenticating against domain-based services (Kerberos authentication for file servers and other resources).

For FreeIPA needs we could look into two different tasks:

• issue keytabs to allow client access using them to kerberized applications from within the containers
• issue keytabs to allow serving kerberized content from within the containers

Below is a braindump, not necessary a valid one. Let's say we added an abstraction CLI that provisions these service accounts. Something like this:

ipa pod-create pod-name
ipa pod-add-container pod-name --container {container1,container2}
ipa pod-associate-host pod-name --hosts {foo1,bar1,zed1}

this would behind the scenes create a service pod-name and add aliases container1 and container2 to it. Then it would make hosts foo1, bar1, zed1 as allowed to manage pod-name service principal and retrieve/generate its key.

At a provision time a host (foo1, for example), would run 'ipa-getkeytab -r' or 'ipa-getkeytab' (depending on whether pod-name already has keys or not and create needed keytabs for each container principal alias using the same key (I tried, it works out of the box already).

As with Windows, 'ipa pod-*' commands would have to be run outside the provisioning flow if we don't want to allow hosts to create these objects on their own.

We lack this kind of automation but I think we have all the bits and pieces to enable us to implement the automation.

Delivering keytabs to containers could be very easily be implemented via a flex volume that drops a configuration snippet in gssproxy with the identity and a unique socket and then bind mounts that socket into the conatiner filesystem where the default gssproxy socket would normally be (or elswhere according to whatever config the pod comes with.