You can admit it. You love Docker because it makes building, testing, and shipping software easier for you. The problem is that attackers love Docker, too. Even if you’re already scanning for Docker container vulnerabilities, your code could still create a data security risk. The good news is that OWASP has your back. Recognizing that developers may not be systems and network security specialists, OWASP established a project specifically focused on Docker container security.
With the shorter version originally published in 2018 and the longer version published in 2019, the current iteration of the Top 10 sits in a GitHub repository. Essentially, the OWASP Docker Top 10 provides a threat model around containers and suggests security measures to mitigate threats.
What are the threats to Docker containers?
The OWASP team breaks down the eight main threats into two primary categories of attacks to:
- Host via network services, protocol flaw, or kernel exploit
- Orchestration via network management backplane
The first five threats all start with the same initial attack vector, where attackers escape the application and container. However, from there, they engage in different behaviors:
- Container escape: Kernel exploit to control all containers running on the host
- Other containers via network: Using shell access to attack another container through the network.
- Attacking orchestration tool via network: Using shell access then attacking the management interfaces or other orchestration tools’ attack surfaces
- Attacking the host via network: Using shell access and attacking an open port from the host
- Attacking other resources via network: Using shell access and finding a network-based vulnerability to exploit
The last three threats cover attacks with different initial vectors:
- Resource starvation: Exploiting a security condition from another container running on the same host
- Host compromise: Compromising the host either through another container or the network
- Integrity of images: Images containing malicious payloads passing from one step to the next in the CD pipeline
OWASP Docker Top 10
To protect Docker containers – or really any container if you can abstract the Docker-specific language OWASP uses – you can implement the security controls outlined below.
D01 – Secure User Mapping
Applications should never run as root because when attackers escape the application, the privileges will follow them. You should run all microservices with the least privilege possible. To ensure this, you should:
- Never use the –privileged flag
- Configure the appropriate parameters for all user IDs or use Linux user namespaces
D02 – Patch Management Strategy
The host, containment technology, orchestration solution, and minimal operating system images may have security vulnerabilities that attackers can exploit.
You should patch often and automate the process. If you are establishing a patch management strategy, you should:
- Specify a time span for “regular basis”
- Create policies or processes for each patch domain
- Execute patches and monitor for success or failure
- Define a policy for critical patches that can’t wait until the next scheduled patch
D03 – Network Segmentation and Firewalling
You should implement a multilayer network defense that denies all access by default and provides access on a case-by-case basis.
When planning your network segmentation and firewall strategy, you should:
- Ensure each tenant is on a different network
- Define necessary communication
- Prevent management frontends/APIs from being exposed to the internet
- Use strict allow-list rules for your management backplane
- Protect host services the same as your management frontends/APIs
For an orchestrated environment, you should have:
- An inbound network and routing policy
- An outbound network and routing policy that restricts downloads from the internet as much as possible
- Determine necessary container inter-communication
D04 – Secure Defaults and Hardening
You should identify and disable all unnecessary network services across interfaces from the following:
- Orchestration tool, like dashboard, etcd, API
- Host, like RPC services, OpenSSHD, avahi, network-based systemd-services
- Container, from the microservice (e.g. spring-boot) or distribution
At the orchestration and host levels, you should identify all services and then review the following:
- Does disabling/stopping it affect the operation?
- Can it be started only on the localhost interface or any other network interface?
- Is authentication configured according to the principle of least privilege?
- Are there configuration options that narrow down the access to this service?
- Are there any known design flaws?
- Are there any known vulnerabilities?
At the container level, you should:
- Uninstall any unnecessary packages
- Review for defective syscalls that can affect the host kernel’s security
- Disable SUID/SGID bits
- Drop more capabilities
D05 – Maintain Security Contexts
Your different environments require different levels of security. You should separate development and testing environments from the production environment. To do this, you should:
- Place production containers on a separate host system and restrict access
- Identify sensitive data types that require additional protection and separate containers accordingly
- Ensure that databases, middleware, authentication services, frontend, and master components are on different hosts
- Use Virtual Machines (VMs) to separate different security contexts
D06 – Protect Secrets
To protect access to a microservice, you should secure passwords, token, private keys, and certificates.
D07 – Resource Protection
Since containers share physical CPU, disks, memory, and network, you need to secure these physical resources to prevent one container from impacting other containers’ resources.
To protect resources, you should:
- Limit the amount of memory a container can use
- Limit the amount of CPU a container can use
D08 – Container Image Integrity and Origin
For the container that runs your code, you should choose a minimal operating system from a trustworthy resource. Additionally, you should scan and monitor all transfers and images at rest.
D09 – Follow Immutable Paradigm
Since deployed container images rarely need to write into their filesystem or a mounted filesystem, you can implement additional security by starting them in read-only mode.
D10 – Logging
To trace all activity, you should log all relevant security events for container images, orchestration tools, and hosts at the system and API levels. Additionally, your application should provide remote logging.
Qwiet AI: Integrating Docker Container Security into Development Processes
With preZero, you can scan all the containers that your applications use and correlate these results with the rest of your application scan. You can integrate the preZero platform into your current CI/CD pipelines, ticketing systems, and development tools. By building security directly into your current processes, our platform enables you to incorporate container security into your secure software development life cycle (SSDLC) processes while still ensuring that you get the speed you need to deliver software on time.
The Qwiet AI platform gives you visibility into the context around vulnerabilities so that you can effectively prioritize remediation actions based on whether attackers can exploit a weakness in your application and account for whether attackers are currently exploiting that vulnerability in the wild.
Take our preZero platform for a free spin or contact us today to see how Qwiet AI can help you build container security into your software development processes.
