BLOG POST

Docker Security – Externalizing Secrets with Conjur

 

June 17, 2014 | DevOps | Kevin Gilpin

 

We have a lot of customers who are excited by Docker, which has prompted us to explore how Docker and Conjur fit together.  In case you’ve been living on the moon, Docker is a technology which allows applications to be packaged into portable containers and then rapidly deployed onto servers or virtual machines. Each Docker container contains all the code and dependencies that an application needs to run, and the Docker runtime is efficient enough to run many containers on a single virtual machine.

06_17_14

Of course, a Docker container doesn’t contain everything that the application needs, because it’s a terrible security practice to build secrets like database passwords and SSL certificates into any deployable bundle (whether tarball, source

code repository, Docker container, etc). Therefore, a Docker container must get its secrets from another source, such as the host operating system or a network service.

This situation got us to thinking about how Conjur Secrets can be used to power Docker containers. We talked over the use cases with our customers, and the result is our latest tutorial, Docker + Conjur Secrets, which shows how Conjur can provide Docker containers with secrets such as database passwords.

How it works

Here’s an example workflow. Alternative mechanisms are also available, with varying features and power. They are described more fully in the Tutorial.

1. A developer builds a new application or service

$ rails new gee-whiz-app

2. A developer or ops team member creates the secret (e.g. by provisioning a new database)

$ passwd=`openssl rand -hex 32`
$ rds-create-db-instance SimCoProd01 -s 10 -c db.m1.large -e mysql -u master -p $passwd

3. A developer or ops team member creates the secret (e.g. by provisioning a new database)

$ passwd=`openssl rand -hex 32`
$ rds-create-db-instance SimCoProd01 -s 10 -c db.m1.large -e mysql -u master -p $passwd

4. The developer or ops team member loads the secret into a Conjur Variable.

$ conjur variable create -v $passwd dev/apps/gee-whiz-app/mysql/password

5. The developer codes the application to retrieve the secret from the process environment

DB.connect user: 'admin', password: ENV['MYSQL_ADMIN_PASSWORD']

6. The application is bundled into a Docker container

$ docker build -t gee-whiz-app ./

7. When the container is started, Conjur fetches the secrets and puts them in the process environment using Docker options. The container then starts up in the normal Docker fashion.

docker run -e -e MYSQL_ADMIN_PASSWORD=`conjur variable value $DEPLOYMENT/apps/gee-whiz-app/mysql/password` gee-whiz-app

8. The application starts up in the container, and its secrets are available!

$ open http://localhost:3000

Benefits

As always, using Conjur to manage and deploy secrets has the following advantages:

  • Secrets are kept out of source control
    : So they aren’t exposed beyond the minimim “need-to-know” privilege
  • Secrets are always kept in memory and never written to disk.
    : So they aren’t captured in images and backups, and then accidentially leaked
  • Permission to update and fetch secrets is rigorously controlled
    : So that production secrets are governed by least privilege principles, while development secrets
    are easy for developers to use and modify
  • Every time a secret is modified or used, a record is written to Conjur
    : So that the usage and permissions of secrets can be easily and automatically audited

If you’re interested in a full code walk-through of Conjur and Docker, head over to the Docker + Conjur Secrets Tutorial on the Conjur web site!

 

Share This