Understanding the container security areas that need to be focused on and particular control recommendations helps to understand which threat needs to be addressed and the areas containers affect most. A few issues and threats are well-known, some are purely lab PoC, and others are threat vectors which offenders have yet to exploit.
Threats to the Build Environment
The primary area which needs to be protected is the built environment. In container security, it is typically the least secure, and the easiest place to insert malicious code. Developers tend to loathe security in development because it slows them down. The developers tend to end-run around security whenever it slows their build and testing processes. Because of this, there is an entire industry dedicated to test data management and data masking.
Malicious or mistaken code changes, configuration scripts with errors, to automated build controllers can be considered as threats. The addition of insecure libraries or down-rev/insecure versions of existing source code. Also, we need to know whether runtime code has been scanned for vulnerabilities.
Runtime Behavior
Developers include tools such as `ssh` in containers so they can modify its
contents on the fly. The difficulty of access rights mapping to OS and host resources by a container, can break operational security and open up the complete stack to several attacks.
Security folks are typically unaware of what container hardening may have been performed. You want to know each container’s contents have been patched, vetted, hardened, and registered before deployment. If a container has open ports for administration, these interfaces may be compromised and used to attack the container engine, the host OS, or other containers.
Operating System Security
The underlying operating system’s security is another concern. The primary question is whether it is configured correctly to limit each container’s access to the subset of resources it needs and to effectively stop everything else. Customers worry that a container will attack the underlying host OS or the container engine. They worry that the container engine may not sufficiently shield the underlying OS. If any attack on the host platform accomplishes, it makes a negative impact on that cluster of containers and can give malicious code enough access to pivot and attack other systems.
Orchestration Manager Security
One of the main reasons to update and reissue this report is this change in the container landscape, where the focus point has shifted to orchestration managers who control containers. As containers have become a commodity unit of application delivery, organizations have begun to understand containers and have shifted to container management. Attentions and innovations have shifting focus on cluster orchestration, with Kubernetes the poster child for value optimization and use of containers. Most of the tools are incredibly complex. Unfortunately, many software products are not focused on security, but the scalability and ease of management of orchestration tools. Also, orchestration tools bring a whole new set of vulnerabilities and security issues. Permission escalation, as well as insecure default configurations and code injection vulnerabilities, are very common. Many of the organizations, issue certificates, identity tokens, and keys from the orchestration manager as containers are launched.
