Mandatory Access Control

Few admins will admit to liking Mandatory Access Control (MAC), but no discussion of container security is complete without at least mentioning the MAC option.

The MAC principle asserts that each user or program should only have access to the resources it actually needs. The most prominent implementations of MAC for Linux are SELinux and AppArmor, and neither of these options is especially popular. Many manuals and how-tos provide instructions for switching SELinux to Permissive mode or deactivating AppArmor right from the outset. Many people don't like to work with MAC, because it sometimes prevents access to files or functions for reasons that are initially difficult to understand.

However, it does not make sense to remove SELinux or AppArmor from the setup right from the start [4]. Docker has gone to great lengths to make SELinux (and AppArmor on Ubuntu systems) as convenient as possible. If you run Docker containers on a host, you should never switch off SELinux completely.

If SELinux or AppArmor block too much, study and customize the profiles instead of killing the entire service. Because the isolation between the host and container in Docker is weaker than in a conventional VM, MAC is a great help for container environments.

Even More Security with Docker Enterprise Edition

If you use Docker on a large scale, you might wish to consider buying the Docker Enterprise Edition (Figure 4). The Enterprise Edition comes with several additional features that are missing in the Community Edition. The most prominent addition is probably the Role-based Access Control (RBAC) system.

Figure 4: Docker's Enterprise Edition comes with full-fledged user management – completely decoupled from the systems.

RBAC makes it possible to connect Docker to an existing user directory, such as LDAP. On the basis of defined roles, it is then possible to determine in a granular manner who can do what in Docker. This option completely decouples Docker user management from the system user management. The Enterprise Edition also comes with some graphical management tools that allow easy configuration for various security functions.

Know the Source

Docker Hub is the largest online exchange for Docker images. If you want to provide a container for the community on the Docker Hub, it's not difficult: First register, then complete some technical details, and then you can start.

Previous articles in ADMIN have already pointed to the inherent dangers of this system several times. Many Docker containers are black boxes, which means that you have to trust that the container creator had noble intentions. Image providers sometimes upload the Docker file on which a container is based to GitHub, thus allowing easy inspection by potential users. Docker Hub, however, has no way to verify that the uploaded image actually matches the referenced Dockerfile.

If you create your own Docker container, be sure to base it on an official distributor image.

If you develop your own containers, you also have to think about how to keep the containers secure in the future: If a security update appears for libraries or programs within the container, the easiest solution is to build the container again from scratch using a Dockerfile with the updated package. This approach presupposes that you operate a complete continuous integration environment for your own containers, such as an environment based on GitLab [5].

Another important security tool is Docker's Content Trust feature, which only lets you download images from another registry that are digitally signed. Docker's registry protocol provides the possibility to tag individual images (Figure 5). The signing function of the Docker registry is based on these tags. Using the docker command, you can create the necessary keys once only and then choose whether or not to digitally sign the tag when tagging images.

Figure 5: The principle of signed tags makes it possible to verify the origin of an image.

If you use the signature function, the docker pull command on the target host lets you enable the signature check by setting parameters. If communication takes place via HTTPS, which is normal for Docker's registry function, the client running on the target host can safely assume that the image loaded from the registry using a signed tag is actually the image uploaded by the key owner – and that the image is unchanged. Even if you don't run your own registry, this function is very practical, because it also works with other remote registry services – if the content trust function is enabled.