Docker Container Security

I’m happy to announce the availability of the latest benchmark addressing the container ecosystem – the Kubernetes 1.7 Security Benchmark. Kubernetes 1.7 brings tons of security improvements. We, at CIS Kubernetes community, have been busy to give you an updated benchmark quickly. Download your copy from the CIS website. For an additional perspective on the release and enterprise-scale capabilities, please check out the google blog.

This version of the benchmark has undergone changes to reflect the above improvements. Below is a quick summary.

Keen to give back to the Kubernetes community and to bring security visibility and agility in Kubernetes deployments, I started the CIS project for developing a security benchmark approximately 10 weeks back. It is humbling to see that in a short time period of 10-weeks, the community came together to document more than 100 recommendations detailed enough for you to take prescriptive actions towards securing your Kubernetes deployments.

When I look back, I was told that Kubernetes security configuration is hugely fragmented and it is a self-dissolving daunting task to document the controls and cover in a benchmark like document. The fragmented offering is just too big a beast to pet. I disagreed and committed.

Here are some interesting thoughts and stats around the 106 recommendations that we have in the benchmark today.

Container security extends into all aspects of the container ecosystem, and not just to the well-known registries like Docker or those offered within the cloud service providers. Securing a container deployment may include best practices for companies supporting: the developer workspace, continuous integration, build automation, testing frameworks, release automation, and operations tools.

Docker yesterday released Version 1.13 and today, we are announcing the release of CIS Docker 1.13 Benchmark, with Cavirin as a key contributor. The CIS Docker community has worked extremely hard to ensure that the time lag between the software availability and security recommendations is almost zero, a leading example of the concurrent availability of security guidance with implementations.

The changelog between CIS Docker 1.12 benchmark and CIS Docker 1.13 benchmark is as follows:

Rules added with the Docker 1.13 benchmark

2.19 Encrypt data exchanged between containers on different nodes on the overlay network

2.20 Apply a daemon-wide custom seccomp profile, if needed

2.21 Avoid experimental features in production

2.22 Use Docker's secret management commands for managing secrets in a Swarm cluster

2.23 Run swarm manager in auto-lock mode

2.24 Rotate swarm manager auto-lock key periodically

Rules modified from Docker 1.12 benchmark

2.8 Enable user namespace support - Updated Audit Procedure

2.5 Avoid container sprawl - Updated Remediation and Audit Procedure

2.3 Keep Docker up to date - Re-worded

Rules deleted in the Docker 1.13 benchmark

1.2 Use the updated Linux Kernel

1.3 Remove all non-essential services from the host

It is easy to understand new additions to the benchmark given the pace of innovation at Docker and the energetic community behind it. But, you might be curious to know why we deleted a couple of rules above?

CIS benchmark development is community-consensus driven. Every change to the benchmark is vetted for consistency, technical accuracy and alignment with current requirements in production.

Rule 1.2 has become obsolete given that most of the Linux distributions are now shipped with the updated kernel that fulfils Docker install kernel requirements. When Docker began, that was really an important thing to check for to run production workloads to ensure reliability.

Rule 1.3 is typically addressed in their respective CIS Linux benchmarks. Hence, this was a duplicate from other benchmarks and got deleted as well. CIS Docker benchmark provides core security guidance for Docker deployments and eliminates obsolete recommendations.

The first step in building a secure infrastructure is to understand the threats. Threats are potential events which lead to something useful for the attacker. It could be money, it could be bragging rights, or it could just be pure fun mutilating the reputation of a business entity. Threat risk modelling is an essential exercise to categorize threats and determine strategies for mitigating them. One such threat assessment model is STRIDE.

STRIDE is an acronym for six threat categories as outlined below:

Spoofing Identity – An attacker could prove that she is an authorized user of the system

Tampering with Data – An attacker could successfully add, modify or delete data

Repudiation – An attacker could deny or make it impossible to prove his delinquency

About Cavirin

Cavirin is the only organization that delivers cyberposture intelligence for the hybrid cloud by providing real-time risk & cybersecurity posture management, continuous compliance, further integrating security into DevOps.