Scenario

You decided it makes sense for you to join the container party and want to containerize your Web app and DB services using docker. That way, web app and DB teams are responsible for their deployment lifecycles. But container operations (starting, stopping, pulling images, checking status) need privileges. Your IT team cannot give users from each of these teams root privileges and per security best practices you want to maintain the separation of duties. So how does Debbie from the database team get access to only the DB stuff without stopping or starting containers of Wes’s web team.

Problems you would like to solve are:

1. Separate docker operations from system administration: So your DB team doesn’t have to file an IT ticket every time they want to start, pause or stop a container.
2. Make sure that the web developers don’t step on the DB team's toes and vice-versa. Don’t want the DB folks to inadvertently stop containers of the web team.
3. Solve this for scale: The company has more than 2,000 servers and needs a way that does not need management of group memberships on a per server level.

Privileges required for Docker operations

Let’s understand the privileges required for docker operations. This will help us achieve our goal of maintaining a secure environment using least privilege access when docker containers are running.

To perform any docker operation, you need to either be root or part of a local group, ‘docker’, on your Linux machine. Why is that? Because access into a docker container is via a UNIX socket and any socket related operations require the user to have privileged access. 'Docker' group membership is sufficient for all container operations, exception is starting the docker daemon itself, which must always run as the root user.

When thinking about separation of duties, this works well because IT admin can decide:

1. a) Whether to run docker daemon on the server or not &
2. b) Which team, based on docker group membership, can actually run their containers on that particular machine.

The members of the docker group can decide which container version they want to run, how many instances of it and so on.

The approach:

1. Plan the AD groups for container management:

Create separate AD groups, one that manages containers for the web team and another that manages containers for the DB team. Members of these groups are the designated individuals belonging to these teams for container operations, not everyone who is a web developer needs to be in the web team. In addition, IT administrators (Ian in this case) may want to be members of all such container management teams as well.

2. Designate Servers for Mutually Trusted applications using Centrify Zones:

Ideally, we would like to be able to use any server to host any container. Because docker group membership allows you to perform operations on any container regardless of what type it is, the only way to prevent different teams from stepping on each other is by assigning dedicated pools of machines per container type.

We will therefore plan to create two different zones:

1. Web Zone – All containers owned by web team can run on any of the machines in this zone.
2. DB Zone – All DB containers can run here.

By using Centrify Zones you would be able to extend the group membership to several hundred machines without having to manually touch each one of them.

What you’ll need:

Identity Infra

-----------------

• Active Directory
• Centrify Zone and Access Manager
• 2 Linux VMs - 1 belonging to the web zone and the other to DB zone. Centrify DirectControl is already installed on them. 
• 2 AD groups, one each for admins of Web and DB zone

Docker Setup

-----------------

• If not available on your linux distribution already, Docker should be installed on the Linux servers (see https://docs.docker.com/installation/)
• Containerized images for the web-app and DB server.
  • In my example, I’m using docker images for tomcat server and PostgreSQL for web and DB containers respectively. More info and available container images here: https://hub.docker.com/
• Local group, ‘docker’, should already be created.

Implementation

Part 1 Setup groups for zones

Step 1: Create zones in Centrify Direct Access Manager called DB and WebDev.

Step 2: In active directory, setup groups for DB and Web teams, who will manage the containers.

Step 3: You now want the groups to be added in the zones created. There are two options here.

Option A: Directly adding groups in child zones

Step 3A: In Centrify DirectManage, go to the DB zone->Groups->rightclick->Create Unix Group and select the DBA group to be added to this child.

Step 3B: Then assign system GID , I picked 999 as its in the range of system GIDs (100-999) and give the linux group name as ‘docker’. Now all members of this DBA group in Active Directory are part of the docker group for all machines in the DB zone.

Option B: With Provisioning from AD to DirectManage enabled

Step 3A: If you want any groups added in AD to be automatically added to Centrify DirectManage:

1. In DirectManage, right click on the Master Zone and enable provisioning.
2. Then add the groups as members of ‘Provisioning Master’ under ‘Provisioning Groups’.

Step 3B: Go to command prompt on the domain controller and type in ‘zoneupdate “Master Zone”’ for the changes to take effect immediately. The groups will now show up in the Master Zone.

Step 3C: Follow the same steps as step 3B of option A discussed above to assign the ‘docker’ UNIX group.

Part 2: Setup computers in the zones

Now that the groups have been setup, we should designate the computers to appropriate zones. I have two computers; I will assign one each to the DB and WebDev zones.

Assumption: The basics steps of having the computers on the same network, DHCP setup, setting DNS and installing Centrify’s agent on the linux machines are already taken care of. We will NOT be covering them here.

Lets first look at what the docker membership looks like on these machines, expectedly returns nothing!

ladmin@ubuntu-db1:~$ getent group docker
ladmin@ubuntu-db1:~$

Let’s proceed.

Step 1: On the machine I want to allocate to the DB zone, I go and type in the following.

root@ubuntu-db1# adjoin -z DB snoopy.test
Administrator@SNOOPY.TEST's password:
Using domain controller: snoopyad.snoopy.test writable=true
Join to domain:snoopy.test, DB successful
 
Centrify DirectControl started.
Initializing cache
 
You have successfully joined the Active Directory domain: snoopy.test
in the Centrify DirectControl zone: CN=DB,CN=Master Zone,CN=Zones,CN=Centrify,CN=Program Data,DC=snoopy,DC=test

Step 2: I go and check in Centrify DirectManage on the DC and see that the machine is added to the zone.

Follow same steps for adding second computer to the DB zone. Just replace the ‘DB’ zone in adjoin command with ‘WebDev’.

Step 3: Verify that the 'DB' group membership in AD is reflected as ‘Docker’ group membership in the zone.

Check for ‘docker’ group membership now, you see that both ‘Ian’ IT Admin and ‘DebbieDBA’ are part of docker group on this machine.

root@ubuntu-db1:/home/ladmin# getent group docker
docker:x:999: debbiedba, ianitadmin

Similarly, on the WebDev machine, Ian and Debbie the DBA are members of docker group.

ladmin@ubuntu-db1:~$ getent group docker
docker:x:999:ianitadmin, weswebdev

Part 3: Launch containers!

Assumption: Root user has already started the docker daemon ('docker -d) on the machine for you. 

Debbie logs into her machine that is in the DB domain.

She starts a postgres docker container, assigns it a name ‘lot-of-postgres’

debbiedba@ubuntu-db1:~$ docker run --name lot-of-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres
928371bbcea17fc0d0f656c3e94278373efebef28bfc4055197cee080046d3f1 

She now checks the status of the container she just started. 

debbiedba@ubuntu-db1:~$ docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS               NAMES
928371bbcea1        postgres:latest     /docker-entrypoint.s   6 seconds ago       Up 5 seconds        5432/tcp            lot-of-postgres     

The postgres container is running, with Unix port 5432 on the machine. Success!!

Now lets say, Debbie inadvertently logged into a machine in the WebDev zone and tries to fire up the postgres container.

debbiedba@ubuntu-webdev1:/home/ladmin$ docker run --name lot-of-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres
2015/09/23 17:12:33 Post http:///var/run/docker.sock/v1.12/containers/create?name=lot-of-postgres: dial unix /var/run/docker.sock: permission denied

Conclusion: We secured our server environment, did not let our DB team step on the Web team’s system and start containers. We used Centrify Zones in Centrify DirectManage to provide this solution that scales to thousands of users and servers.

This solution provides a separation of duties not only between IT and devops but also between different teams deploying their services. By leveraging zone structure, we have overcome the security risks that would have been introduced had all zone admins were part of docker group on all computers.

Here's a short video going over the solution and demo:

Additional reference: Docker TechCenter