Tips to Secure Docker & Kubernetes

Like all technologies docker introduces new challenges with security and risk that need to be addressed. A compromised docker container can lead to other containers being compromised as well as the underlying operating system. There are several CVE’s that have been published over the last few years so make sure your containers are secure, and that your devops team introduce security early on in the SDLC

Some Best Practices

  • The most obvious – always run the most updated version of Docker
  • Decrease your Docker deamon attack surface with user trusted groups
  • Rules to Audit
  • Secure docker files & directories
  • Don’t allow containers to acquire new privileges
  • Don’t run as root or with the privilege flag set
  • Only use trusted base images
  • Implement a strong governance policy
  • Frequent vulnerability Scanning
  • Don’t’ store your secrets in Docker/Containers
  • Don’t install sshd for management of containers
  • Set the containers root file system to read-only
  • Impose PID limits in each container, the fewer processes the better.
  • Don’t use the default bridge docker0
  • Dump your logs into your SIEM platform, rule and alert accordingly

Use publicly available tools sets to help you manage your security, Docker Bench from https://github.com/docker/docker-bench-security is based off CIS benchmarks that give you an overall view of your security posture.

You can get a copy of the CIS Docker benchmarks here https://www.cisecurity.org/benchmark/docker/

Other variations are possible too to keep track of Open Source Vulnerabilities such as

Orchestration and Kubernetes are also not without its security issues, there are known publicly available exploits also.

https://github.com/aquasecurity/kube-hunter

Kuber-hunter allows for some very nice flexible options when scanning. You can run directly from your local machine for remote scanning, run it directly on a machine in a cluster to probe all the local network interfaces and you can also run it in a pod within a cluster, this is my preferred option as it indicates how exposed your cluster would be if one of your applications pods becomes compromised.

Some Kubernetes best practices

  • Sort our your RBAC, remove unnecessary roles, don’t duplicate permissions don’t grant cluster-admin privileges to users or groups of users
  • Create an appropriate network policy if internet access is required on your pods
  • Use Kubernetes network policies to isolate your pods only allow communication paths that allow the application to function
  • Use the PodSecurityPolicy admission controller
  • Make sure untrusted registries are automatically denied.

Leave a Reply

Your email address will not be published. Required fields are marked *