Author: Aly Khimji


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.

>>> Pull a base container
]# docker pull fedora:latest
Trying to pull repository docker.io/library/fedora ...
latest: Pulling from docker.io/library/fedora
ffa7676a36a8: Pull complete
Digest: sha256:be1e975ca0832971c21e6876eeea4d2a117ee21d0603fb9eb61ab8ce4ac0e34e
Status: Downloaded newer image for docker.io/fedora:latest

>>> Install some libraries and common pkgs
]# docker run -it docker.io/fedora /bin/bash
dnf install -y sssd-client sssd-krb5-common sudo libsss_idmap libsss_nss_idmap 
libsss_sudo sssd-common krb5-workstation krb5-lib

>>> Commit the changes to a new image
]# docker commit fe151d51ca08 fedora-auth:latest

>>> Bind-mount our SSSD sockets into our container
]# docker run -it --rm -h oracledocker00.arctiq.lab 
-v=/var/lib/sss/pipes/:/var/lib/sss/pipes:rw fedora-auth:latest /bin/bash

Now lets test some identity look ups

>>> Fetching of IdM users
[[email protected] /]# id admin
uid=174400000(admin) gid=174400000(admins) groups=174400000(admins)

>>> Fetching of AD users
[[email protected] /]# id [email protected]
uid=1180200500([email protected]) 
gid=1180200500([email protected]) 
groups=1180200500([email protected]),1180200520(group policy 
creator [email protected]),1180200519(enterprise [email protected]),1180200512(domain 
[email protected]),1180200518(schema 
[email protected]),1180200513(domain 
[email protected]),174400004(ad_admins)

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.

docker run \
 --volume=/var/lib/sss/pipes/:/var/lib/sss/pipes/:rw  \
 --volume=/etc/sssd/:/etc/sssd/:ro  \
 --volume=/etc/krb5.conf:/etc/krb5.conf:ro \
 --volume=/etc/ipa/ca.crt:/etc/ipa/ca.crt:ro  \
 --volume=/etc/nsswitch.conf:/etc/nsswitch.conf:ro \
 --volume=/etc/pam.d/:/etc/pam.d/:ro \
 -h oracledocker00.arctiq.lab  fedora-auth:latest /bin/bash

More testing...
>>> Authentication of IdM/AD users 
-bash-4.2$ su - admin
Password:                  ← password auth working
Last login: Tue Mar  7 21:49:27 UTC 2017 on console
-bash-4.2$ whoami
admin

-bash-4.2$ su - [email protected]
Password:                   ←  password auth working
Last login: Tue Mar  7 21:04:33 UTC 2017 on console
-sh-4.2$ whoami
[email protected]

>>> Kerberos 
-sh-4.2$ kinit
Password for [email protected]:
-sh-4.2$ klist
Ticket cache: FILE:/tmp/krb5cc_1180200500
Default principal: [email protected]
Valid starting     Expires            Service principal
03/07/17 21:50:10  03/08/17 07:50:10  krbtgt/[email protected]
        renew until 03/08/17 21:50:09

>>> SUDO 
(this requires creating a host entry in IdM and setting a fixed hostname on the container 
at run time, but this is expected with sudo)

-sh-4.2$ sudo -l
[sudo] password for [email protected]:
User [email protected] may run the following commands on this host:
    (ALL : ALL) /usr/bin/vi, /usr/bin/ls
-sh-4.2$

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.

//take the first step

Tagged:



//comments