11 April,19 at 11:49 AM
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:
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:
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:
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.
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:
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
-----------------
Docker Setup
-----------------
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:
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