Automatic Kerberos Ticket Creation in Kubernetes with Posit Helm

The goal of this repository is to serve as a reference point for customers who are in the unfortunate situation of needing Kerberos tooling available in Kubernetes, and more than that, for customers who need access to automatically generate Kerberos tickets when a session starts, rather than when a user manually runs kinit. This functionality can be important in situations where customers need access to CIFS shares that use Kerberos/AD security. For awhile, this configuration has been a particular challenge, because domain joining Kubernetes cluster nodes is difficult at best and impossible at worst. This means that the standard means for getting AD Kerberos tokens into pods doesn't work. This configuration enables customers to use SSSD/PAM for user authentication and to use native Kerberos functionality in Ubuntu 22 to get Kerberos tickets. Portions of this configuration are relevant for customers who still need SSO authentication, but the automatic forwarding of passwords from the Workbench pod to the session pod is only possible if the Workbench Pods use PAM authentication.

There are 4 key components to this configuration:

1. Customized Docker images for the Workbench, Session and SSSD sidecar containers
2. The customers valid and tested sssd.conf file, potentially to include valid TLS certificates for secure connectivity to their AD server
3. The customers valid and tested krb5.conf file
4. The helm chart values file included in this repository

These 4 classes of artifacts are included as examples in this repository and have been tested and are known to work together, once they have been appropriately customized for a users Keberos and LDAP domains. The implementation in this repository does not require the Kubernetes nodes to be domain joined.

Trade-Off

There are several security related trade-offs that have to be allowed for with this configuration.

1. Session pods need the ability to connect to a customers LDAP/Kerberos servers and require an SSSD sidecar container that runs as root. The primary pod container that users interact with still runs as the specific user, but that sidecar could introduce a potential exploit/escape mechanism. This has to be weighed against the additional security that using Kerberos tickets to connect to network shares and other resources provides
2. SSO functionality within Workbench does not work out of the box. Because Workbench needs access to user passwords, PAM authentication is required. This can be worked around through several means, such as an intermediate authenticating proxy which manages a users SSO authentication, then passes them back to Workbench. But it's still a compromise and if not carefully architected around, could lead to directly exposing Workbench using PAM authentication to their internal customers.