As Infrastructure and Application Development continue to converge in a Dev Ops world, container technology is being heavily adopted by organizations.  As a trusted security partner, Centrify customers and prospects are asking how can Centrify secure this new dynamic container based eco system? 

@David covered in his article how Centrify can control both access and privileges across a containerized ecosystem with the Centrify Identity Platform.  This blog will showcase several of those best practices using Github and DockerHub published resources.  In particular, we will demonstrate:

• How to automatically vault the root account of a launched container to enable break glass access
• How to automatically enroll containers with the Centrify Identity Platform and provision a unique certificate the container can use to interact with the Centrify Platform (i.e. retrieve a managed credential/secret)
• How to provide corporate users (AD/LDAP users) the ability to authenticate to containers without the need to join containers to Active Directory by leveraging the Centrify platform's identity broker capability

For this howto, we make the following assumptions:

• Containers have no connectivity to the core network (i.e. no direct Active Directory/LDAP connectivity).  Containers can run anywhere, AWS, GCP, Azure, DMZ, etc.  
  • For those familiar with Centrify, we will not be using the agent that joins systems to AD directly since a key assumption is that AD connectivity does not exist.  Further users may be in AD, LDAP or other directories.
• We will use CoreOS to host the container and manage the container with Docker

Before getting started, I want to give a shout out to Albert Leung, Senior Software Architect with Centrify, for leading the Engineering efforts on this project and for his feedback on this Blog.  Thank you Albert!

Let's get started by first reviewing a high-level architecture diagram and the components needed to secure containers with this model:

• Centrify Identity Platform - Can be subscribed to in the cloud or be customer deployed, delivers the core security services like AD/LDAP authentication, PKI, shared account password management
• Centrify Agent - Delivers authentication, access control, shared account credential management services to systems/containers
• Centrify Connector - Allows the Centrify Identity Platform to broker the authentication requests to AD/LDAP without any direct connectivity to the on premise environment

Step 1: Pull the official Centrify Docker image from Docker hub:  

$ docker pull centrify/cloud-agent
Using default tag: latest
latest: Pulling from centrify/cloud-agent
18b8eb7e7f01: Pull complete 
61f71e899d26: Pull complete 
17ca11330928: Pull complete 
c130733c27e1: Pull complete 
72195ac0d01d: Pull complete 
0ae183f4a385: Pull complete 
c38ad14074e2: Pull complete 
134778296f70: Pull complete 
caa5f1270f84: Pull complete 
6a6962d8e9e4: Pull complete 
Digest: sha256:19bb4f67385921f77a5fadd9621fa769c4794184e4bcd8650dc7455b1c102e52

If you would like to modify the image, you can build your own image by downloading the files from the Centrify docker-files Github repo and running docker build

$ git clone git://github.com/centrify/docker_files
Cloning into 'docker_files'...
remote: Counting objects: 18, done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 18 (delta 2), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (18/18), 9.07 KiB | 9.07 MiB/s, done.
Resolving deltas: 100% (2/2), done.
$ cd docker_files/
$ ls
LICENSE.md  README.md  centrify_agent_for_linux
$ cd centrify_agent_for_linux/
$ ls
README.md  centrifycc-unenroll.service  cjoin_startup.sh  dockerfile.centos.cjoin

$ docker image build -t "centos:cjoin" -f ./dockerfile.centos.cjoin .

For this howto, we will use the Dockerhub published image.  The image uses the base Docker centos image and layers on top:

• Latest Centos updates
• The new Centrify agent
• OpenSSH since we want to allow users to logon to the container with corporate credentials.  Many customers allow logons to Dev containers to test, for example.
• A service to un-enroll the container from Centrify when the container is stopped.  This helps with automated clean-up.
• A script to automate the enrollment of the system to the Centrify Identity Platform

Step 2: Now that we have our image, let's run the container.  Before we run the container, we need to obtain information about our environment to provide the docker run command.  For this howto, we will be providing users with SSH access to the container plus securing the container's root account for break glass access.  To accomplish all of this automatically, we will use the following variables with the details of our environment.  Refer to the README.MD for details on all the variables available:

• URL - aaa5678.my-cloud.centrify.com  
  • Centrify Identity Platform Tenant URL
• CODE - 4GB78745-8HTG-OYHF-HYGT-NJHYF14A5E4E 
  • An Enrollment Code can be created in the Admin portal by visiting Settings --> Infrastructure --> Enrollment Codes.  Enrollment codes allow the automatic enrollment of systems to the Centrify platform
• LOGIN_ROLE - Consultants_SystemEngineers,TechSupport
  • Members of these Roles will be able to access the system.  In this environment, we have Active Directory groups as members of these roles to drive access using the internal AD controls
• PORT - 2010
  • This is the port OpenSSH will listen on the running container.  My CoreOS host is already listening on port 22, therefore using 2010
• NAME - secure_container
  • The name of the container used during the enrollment process
• ADDRESS - 10.10.40.34
  • Routable IP Address of the container.  In our case, the IP address of the CoreOS host
• VAULT_ROOT_PASSWD - yes
  • Tells the automation to change and securely store the root password in the Centrify Identity Platform
• MANAGE_ROOT_PASSWD - yes
  • Configures the Identity Platform to rotate the root password based on policy and checkout/check-in.
• LOGIN_AS_ROOT_ROLES - Consultants_SystemEngineers,TechSupport
  • Grants members of these Roles access to checkout/login with the managed root account
• ENABLE_USE_MY_ACCOUNT - yes
  • Sets up the container to certificate based authentication

In addition, we will provide the arguments "-d -p 2010:22 -v /sys/fs/cgroup:/sys/fs/cgroup --cap-add=SYS_ADMIN --name secure_container" to docker run to run the container in detached mode, enable logons and expose port 2010 to allow connectivity to the container.   

We will now run the docker run command to run the container based on created image centos:cjoin in Step 2:

~/docker_files/centrify_agent_for_linux $ docker container run -d -p 2010:22 -v /sys/fs/cgroup:/sys/fs/cgroup --cap-add=SYS_ADMIN --name secure_container \
  -e CODE=1BA7983D-5EE6-4AAD-A22C-8BD3F14A5E4E -e PORT=2010 -e URL=aaa5678.my-cloud.centrify.com \
  -e VAULT_ROOT_PASSWD=yes -e MANAGE_ROOT_PASSWD=yes -e LOGIN_AS_ROOT_ROLES=Consultants_SystemEngineers,TechSupport -e ENABLE_USE_MY_ACCOUNT=yes \
  -e NAME=secure_container -e ADDRESS=10.10.40.34 -e LOGIN_ROLE=Consultants_SystemEngineers,TechSupport centrify/cloud-agent
64e14b527cf70fcdf2589968f23e8de67acf2e6580ec7ff620c0344f43e3427c

Docker returns an instance id if the container was successfully launched. Let's check the container is running and the enrollment to the Centrify Identity Platform was successful:

$ docker container logs secure_container
current tenant URL:  aaa5678.my-cloud.centrify.com
IP address to use: 10.10.40.34
host name to use: secure_container
current setting for PORT: 2010
connectors setting: 
login role:  Consultants_SystemEngineers,TechSupport
ENABLE_USE_MY_ACCOUNT: 
UseMyAccount: Y
VAULT_ROOT_PASSWD: yes
VaultRootPasswd: Y
LOGIN_AS_ROOT_ROLES: Consultants_SystemEngineers,TechSupport
MANAGE_ROOT_PASSWD: yes
ManageRootPasswd: true
Machine is not enrolled in Centrify identity platform.
Enrolling in Centrify identity platform https://aaa5678.my-cloud.centrify.com/ using enrollment code...


Feature enabled: Application-to-Application Password Management
Feature enabled: Centrify Agent Authentication

Starting Centrify agent...
Centrify agent started.

You have successfully enrolled in Centrify identity platform: https://aaa5678.my-cloud.centrify.com/

You may need to restart other services that rely upon PAM and NSS or simply
reboot the computer for proper operations. Failure to do so may result in
login problems for Centrify identity platform users.


$ docker container exec -it secure_container cinfo
Enrolled in:      https://aaa5678.my-cloud.centrify.com/
Enrolled as:
    Service account:  secure_container$@centrify.com.18754
    Resource name:    secure_container
    IP/DNS name:      10.10.40.34
    Owner:            CentrifyAmazonSSO-EC2Admins (Type: Role)
Customer ID:    AAA5678

Now that the container has been enrolled to the platform, members of the Consultants_SystemEngineers and TechSupport groups can logon to the container with their corporate credentials.  Members of these roles can also checkout the password to the root account or login with the root account via the Centrify Identity Platform.

Step 3: Validating user access, root break glass procedure and programmatic access to credentials/secrets

Now that the container is enrolled, let's validate and demonstrate the benefits of the Centrify Identity Platform. 

First, let's validate an AD user, felderi.santiago@centrifylab.net, that's a member of the Consultants_SystemEngineers role/AD group can login to the system:

$ ssh -l felderi.santiago@centrifylab.net 10.10.40.34 -p 2010
The authenticity of host '[10.10.40.34]:2010 ([10.10.40.34]:2010)' can't be established.
ECDSA key fingerprint is SHA256:308Pqj3gG5WW6Itwqbpm6pGeGPgsKq3RzDMKZsJ7Oq0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[10.10.40.34]:2010' (ECDSA) to the list of known hosts.
Password: 
Created home directory
$ id
uid=3278713086(felderi.santiago) gid=3278713086(felderi.santiago) groups=3278713086(felderi.santiago) context=unconfined_u:unconfined_r:unconfined_t:s0

If the user doesn't have direct network connectivity to the container, we can leverage the platforms's remote access capabilities to connect and to not require entering passwords, use the My Account feature which uses temporary PKI certificates in leiu of passwords to authenticate.

As we can see, the user was able to logon to the container, with their AD credentials, without the container needing to join AD directly and their home directory was created.  Further, we demonstrated the user can connect with no connectivity to the host required and without even needing to enter a password. 

This means the container can be deployed anywhere and users can logon with their corporate identity even without having to expose their corporate credentials.  Just as important, the internal process of managing groups can drive access regardless of where the container lives (on prem/cloud or hybrid) and when the user leaves the company, the AD account is disabled and they lose access.

Let's now validate break glass. For example, say this user needs root level access on the container to troubleshoot something.  Since the user is in the Consultants_SystemEngineers role, the user can check out the managed root password from the Centrify platform.

To do this, the user can visit the Centrify Identity Platform's Admin Portal: https://aaa5678.my-cloud.centrify.com/manage and can logon on with their corporate credentials.  Once logged in, the user visits the Infrastructure --> Systems menu and searches for the container, which in this case we named secure_container.  

Clicking on the container, the user sees the root account associated with the container and based on his permissions, can check out the root password.  

Let's make sure the user can become root using the password checkout:

[felderi.santiago@e8db0beedc6a ~]$ su - 
Password: 
Last login: Thu Apr 19 18:57:39 UTC 2018 from 10.10.45.33 on pts/0

Users can also login as root without checking out the root password as long as SSH PermitRootLogin is enabled. 

Another option is to not grant users rights to checkout or login as root and instead turn on workflow based access or just in time access.  This method requires users to request access to the account, approvers validate and approve the request before users are able to use the account.

If we take a look at the Identity Platform's Activity for this system, we notice all actions are always attributed back to the end user, regardless of how they connected to the system:

 04/19/2018 02:55 PMfelderi.santiago@centrify.com checked out local account "root" password for "secure_container"(10.10.40.34)
 04/19/2018 03:51 PMfelderi.santiago@centrifylab.net logged in to system "secure_container"(10.10.40.34) using account "felderi.santiago@centrifylab.net" via Ssh
 04/19/2018 03:56 PMfelderi.santiago@centrifylab.net logged in to system "secure_container"(10.10.40.34) using local account "root" via Ssh 

Lastly, let's validate programmatic access to the managed credentials.  To do this, we will use the cgetaccount CLI provided by the Centrify agent.  The cgetaccount CLI needs to run as root since it uses the certificate provisioned during enrollment to authenticate to the Centrify platform and uses the machine identity to checkout the secret.  This allows for example, container A to checkout the password to an account on Container B as long as the user on Container A can run cgetaccount as root and the Container A identity has rights to checkout the password to the user on Container B. 

$ password="$(sudo cgetaccount --lifetime 30 --type system --silent secure_container/root)"
$ 
$ echo $password
{6*YATU9jY(|eW=

 Another option to checkout the credentials programatically is to use the Centrify RESTAPI.

Step 4:  Cleaning up the Container

One of the great things about containers is their flexibility.  If an application needs more capacity, more containers are launched, if less capacity is needed, containers are spun down.  We showed above how containers are automatically enrolled and secured when launched.  When containers are spun down, we want to clean up.  As part of this automation, a clean up service is installed and enabled which removes the system from the Centrify platform when the container  is stopped or removed.

To see this in action, we simply need to run the docker stop command:

$ docker container stop -t 180 secure_container

This will remove the system from the Centrify platform:

 If the container is started again, the system will be re-enrolled automatically as well.

This concludes this how to.  In summary, we've covered how the Centrify Identity Platform can be used to automate the security of containers to accomplish:

• How to automatically vault the root account of a launched container to enable break glass access
• How to automatically enroll containers with the Centrify Identity Platform and provision a unique certificate the container can use to interact with the Centrify Platform (i.e. retrieve a managed credential/secret)
• How to provide corporate users (AD/LDAP users) the ability to authenticate to containers without the need to join the containers to Active Directory by leveraging the Centrify platform's identity broker capability

We hope you found this howto useful.  If you have questions or feedback, please leave us a comment. 

Thanks for reading,

Felderi Santiago

VP of Enterprise Solutions

Centrify Corporation