11 April,19 at 11:50 AM
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:
For this howto, we make the following assumptions:
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:
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:
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:
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:
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