With the rapid adoption of containers throughout the industry, the landscape of technology and tools in the enterprise is forever changing. Once the excitement of getting the technology up and running wears off, we are often left with the same questions we find enterprises regularly asking.
“How do I get access control inside my container?”
“How can I get my central user base visible inside my container?”
“How do I get sudo controls inside my container?”
“How can I use Kerberos inside my container?”
“What level of interaction should we be having with our containers?”
The best practice for a container dictates having only one running process / service (ideally), so having a container with a running SSSD process for authentication and any additional demons all along side your application process is not ideal.
At Arctiq we are always trying to experiment and solve new problems before there are clear cut reference architectures defined. This requires us to conduct lots of “Proof of Concepts” using new technologies and also think out of the box to obtain a proven opinion and recommendations for our clients.
For this proof of concept we are looking deeper into container security; specifically how identity and access management applies to containerized applications. In this use case we will attempt to stand up a vanilla Fedora container, install some base SSSD, kerberos, and sudo library packages. Then try and see if we can plumb down the full functioning authentication stack from our Docker host into our container.
Our Docker host is a RHEL 7.2 machine that is fully integrated into a Red Hat IdM environment. This IdM environment has a one way trust to a Active Directory domain to allow AD resources to access resources in our IdM environment. This is a pretty standard setup for most IdM enabled enterprises.
The secret behind enabling identity look up into our containers is to bind mount the SSSD sockets of the running Docker host into the container. We mount a section of the Docker hosts filesystem into the container’s filesystem, and then leverage the mount that SSSD sockets communicate over within the container. This will allow the SSSD client libraries to authenticate against the SSSD process running on the host. We will then use SSSD on the host to authenticate against our back end IdM and Active Directory domains.
Okay that’s great, now let’s see if we can mount some of the authentication configuration files as RO into the container. Doing this will allow us to leverage the same pam, kerberos, nsswitch and sudo related configurations down into the container that is available on our host. This will allow us to expose more configuration settings without making changes to the container whilst allowing us to leverage these services more effectively.
Let’s bind mount as RO the following volumes.
There you have it. With minimal changes to the container environment, without adding any additional processes, we are able to introduce some authentication and authorization controls to our container. We also have kerberos available, which we can now pipe back into kerberos aware applications so they can leverage IdM and Active Directory SPNs and authentication.
Some other methods for those using the Red Hat Atomic platform, would be using SPC’s (super privileged containers). RHEL Atomic System Security Services Daemon (SSSD) Container Image allows the Red Hat Enterprise Linux Atomic Host authentication subsystem to be connected to central identity providers like Red Hat Identity Management and Microsoft Active Directory. This can also be leveraged by other containers on the Atomic platform which would allow for the same look up capabilities as we have discussed above. Take a look here for more details. For those interested in similar concepts for Windows look here. Keep an eye out for more Arctiq Blog’s on this topic, security is important and should not be an afterthought.
Interested in exploring the wonderful world of container security further?
Reach out to us, we would love to have a more detailed discussion.