[TBD]Container security key-points

Container in security scan

• Those users far prefer performance to security for their single-tenant workloads may wish for VM-like lifecycle management in container without the overhead imposed by virtualization.

• For those that depend on VMs for security, Docker is not an alternative, but a complement.

• SeLinux can be used to secure your processes

• Unfortunately, what has not existed as a strong movement is DevSecOps (or SecDevOps). As DevOps practices lean heavily into the purview of “No Ops”, a focus on security may be lost.

• Using Docker, a stricter-than-average set of capabilities are set by default. Accessing an even stricter set of capabilities is possible with a few command-line arguments.

Docker way for enforcing security

• • Protection via view isolation- 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.

  • Protection against networking attack - Each container also gets its own network stack. As an example, a container doesn’t get privileged access to the sockets or interfaces of another container.

• Protection against DOS - Control Groups are key component of Linux Containers. It helps ensure that each container gets its fair share of memory, CPU, disk I/O; and, more importantly, that a single container cannot bring the system down by exhausting one of those resources.

Docker attack surface

Host file system manipulation:

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. This has a strong security implication

Mitigation: If you instrument Docker from a web server to provision containers through an API, you should be even more careful than usual with parameter checking, to make sure that a malicious user cannot pass crafted parameters causing Docker to create arbitrary containers.

Mitigation: only trusted users should be allowed to control your Docker daemon

Attack via docker load and docker pull

A malicious attacker can embed malware in the image

Mitigation: All images are stored and accessed by the cryptographic checksums of their contents, limiting the possibility of an attacker causing a collision with an existing image.

Attack via docker daemon hijack

Docker daemon runs as root process. Hijacking of docker daemon can have large impact

Mitigation: Run exclusively Docker on the server, and move all other services within containers controlled by Docker.

Reference

https://medium.com/@ewindisch/on-the-security-of-containers-2c60ffe25a9e

https://docs.docker.com/engine/security/security/