Container Security

Recently I just provided one talk regarding container security in InfoSec Taiwan 2020 conference for Cloud Security Alliance community. Microservice is the most popular topic for about 3~5 years. Containerize your services is the main approach to orchestra your microservice. Gartner also predicts that by 2023, 70% of organizations will be running three or more containerized application in production.

In the past, developer and tester uses virtual machine to develop and test their product. When container technology comes out, all of them jump into it to expedite the whole development circle. Container technology provides the more convenience and fast way to boot one virtual environment for any purpose but it’s not totally isolated and causes some security issues. I will use docker as a container runtime for demo in this article to talk about it.

0x01 Categories of Container Security Issue

There are five container security issue categories defined in NIST 800–190. I list below:

1. Host OS Risk
2. Orchestration System Risks
3. Container Runtime Risks
4. Registry Risks
5. Images Risks

I will not describe all of them. Please refer the following PDF.
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf

0x02 Security Issues

There are some common container security issues I would like to address and I will have some detail description below:

0x021 Container should not run as ROOT

The first container security issue I would like to address is DO NOT RUN CONTAINER AS ROOT. The container does not have its own kernel. It relies on the host kernel, so the user inside of the docker container with uid 0 is the same user on the host system with uid 0. And the user with uid 0 is a root. So he has full privileges. Let’s see the following example:

Root user inside container

Please use non-root user in your Dockerfile to build your containerize application:

non-root user dockerfile

0x022 Privileged Container is so BAD

Privileged containers are containers that have all of the root capabilities of a host machine, allowing the ability to access resources which are not accessible in containers. One use case is when you’re inside one privileged container, you can access all dev files under /dev folder of the host and then you can mount the host root folder inside the container and read/write files whatever you want !!! Please see the following example:

Inside Privileged Container

You can also utilize cgroups v1 release_agent feature to do your arbitrary command execution inside container. Please see Felix Wilhelm’s twitter.

0x023 BAD Container Image

Some malicious actors would build their bad container image which contain cryptocurrency mining program or other malware and put it onto public registry. They may use some way to attract you to use it as your base container image. Once you deploy it, you will help them to do their cryptocurrency mining job. Please see below example:

Bad image

0x024 Open Docker API

If you use docker as your container runtime, please be careful about this issue. Docker by default will only listen on Unix socket (unix:///var/run/docker.sock), but for some reason, someone might open it on TCP port 2375(tcp) or 2376(ssl/tls). Malicious actors will easily use docker command to create one privileged container on your host. See below:

Open Docker API

0x025 Attack Scenario

So there are 3 attack scenarios that happen to attack your container environment, like your docker host or Kubernetes cluster. Please see the following diagrams:

Attack Scenario 1

Attack Scenario 2

Attack Scenario 3

0x03 Conclusion

Above are the common container security issues and attack scenarios happened in this real world. Realizing all the weakness and harden your container environment is the best way to survive in this quick changing world. If you are interested in any container security topic, please PM me or give me your claps. Thanks.

0x04 References

Container Escape 101

Understanding Docker container escapes