Docker Security for containers

 Docker Security

Docker is the most popular containerisation technology. Upon proper use, it can increase the level of security (in comparison to running applications directly on the host). On the other hand, some misconfigurations can lead to downgrade the level of security or even introduce new vulnerabilities.There are common container security risks and vulnerabilities during a development cycle that can be exploited be attackers.

1. Using insecure images

2. Containers running with the privileged flag

3. Unrestricted communication between containers

4. Containers running rogue or malicious processes

5. Containers that are not properly isolated from the host

Using insecure images:

Containers are built using images. Images are useful for building containers because you can reuse the various components of an image instead of building a container image from scratch. However, like any piece of code, images or their dependencies could contain vulnerabilities. 

You should always try to use images from trusted sources. What i mean by that is if I am going to download mssql image from docker hub then it should be from microsoft only. Others images also could be used for downloading mssql but you don't know which image could be containing vulnerabilities.

Containers running with the privileged flag

Anyone with even a modest knowledge of containers might know what a privileged container is. Containers running with the privileged flag can do almost anything a host can do, run with all capabilities and gain access to the host’s devices. This means that if an attacker breaches a container running with the privileged flag, then he can do anything on host's system.

Executing container engines with the --privileged flag tells the engine to launch the container process without any further "security" lockdown.

docker run --privileged -t -i --rm ubuntu:latest bash 

You can use cap_add instead.

 docker run --cap_add SYS_ADMIN ...

Unrestricted communication between containers

Docker containers are very similar to LXC containers, and they have similar security features. When you start a container with docker run, behind the scenes Docker creates a set of namespaces and control groups for the container.

Namespaces provide the first and most straightforward form of isolation: processes running within a container cannot see, and even less affect, processes running in another container, or in the host system.

Each container also gets its own network stack, meaning that a container doesn’t get privileged access to the sockets or interfaces of another container.

Running containers (and applications) with Docker implies running the Docker daemon. This daemon requires root privileges unless you opt-in to Rootless Mode, and you should therefore be aware of some important details. First of all, only trusted users should be allowed to control your Docker daemon. This is a direct consequence of some powerful Docker features. Specifically, Docker allows you to share a directory between the Docker host and a guest container; and it allows you to do so without limiting the access rights of the container. This means that you can start a container where the /host directory is the / directory on your host; and the container can alter your host filesystem without any restriction. 

Containers running rogue or malicious processes

Tracking containers if one of them is running malicious code could be hard because there could be lots of containers. So you can use Docker’s CAP ADD feature to add only those Linux capabilities necessary for a container to run properly and achieve its goal and use CAP DROP to remove all unnecessary capabilities.

Containers that are not properly isolated from the host

Any misconfiguration to container can put the host at risk. 

Don’t share the host’s network namespace. Doing so could put you at risk of a container shutting  
down  the Docker host.

Don’t share the host’s process namespaces. Doing so would allow a container to see all of the processes running on a host system, which leaves the processes on the host at risk of being manipulated or shut down.

There are few things could be followed

• Always Keep Host and Docker up to date.

To prevent from known, container escapes vulnerabilities, which typically end in escalating to root/administrator privileges, patching Docker Engine and Docker Machine is crucial.

• Do not expose the Docker daemon socket (even to the containers)

Docker socket /var/run/docker.sock is the UNIX socket that Docker is listening to. This is the primary entry point for the Docker API. The owner of this socket is root. Giving someone access to it is equivalent to giving unrestricted root access to your host.

Do not enable tcp Docker daemon socket. If you are running docker daemon with -H  tcp://0.0.0.0:XXX or similar you are exposing un-encrypted and unauthenticated direct access  to the Docker daemon, if the host is internet connected this means the docker daemon on  your computer can be used by anyone from the public internet.

• Set User

Configuring the container to use an unprivileged user is the best way to prevent privilege escalation attacks. This can be accomplished in few different ways as follows:

During runtime using -u option of docker run:

docker run -u 4000 alpine         

During build time. Simple add user in Dockerfile and use it. For example:

FROM alpine   

RUN groupadd -r myuser && useradd -r -g myuser myuser      

• Add –no-new-privileges flag

Always run you docker images with --security-opt=no-new-privileges in order to prevent escalate privileges using setuid or setqid binaries.

In kubernetes, this can be configured in security context using allowPrivilegeEscalation field. 

• Disable inter-container communication (--icc=false)

 

By default inter-container communication(icc) is enabled - it means that all containers can talk with each other using (docker0 bridged network). This can be disabled by running docker daemon with --icc=false flag. If icc is disabled (icc=false) it is required to tell which container can communicate using --link=container_name or id:ALIAS option.

Conclusions

Docker containers are, by default, quite secure; especially if you run your processes as non-privileged users inside the container. You just need to handle the configuration of containers carefully.

Note: If you think this helped you and you want to learn more stuff on devops, then I would recommend joining the Kodecloud devops course and go for the complete certification path by clicking this link