BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News NIST Publishes Guidelines on Application Container Security

NIST Publishes Guidelines on Application Container Security

This item in japanese

The National Institute of Standards and Technology (NIST) published a bulletin on application container technology and its most notable security challenges. The report is a summary of two previous bulletins outlining vulnerability areas including image, registry, orchestrator, container, host OS, and hardware, and their countermeasures.

NIST’s Computer Security Research Center (CSRC) oversees cyber and information security related projects and publications from NIST. The current bulletin is a summary of two previous publications on application container security. It begins with a summary of application containers, followed by factors that affect security, and ends with countermeasures that can help with improving app container security.

The portability of containers and their immutable nature can lead to two distinct areas where security issues can creep in. Containers provide a higher-level abstraction than an app archive to distribute and deploy the application. They are typically designed to be portable across environments and machine architectures, since the same container image is expected to be usable across different environments of dev, testing and production. These practices which have benefits for app portability and continuous delivery environments can also lead to possible security issues. Security tools and processes cannot make assumptions about the specific environments that the containers would run on. This can lead to loopholes since many security vulnerabilities are specific to the environment.

Containers work on the immutable model - when a new version of a container is published as an image, the old container is destroyed and a newly created one takes its place. When the base image is updated, e.g. as an operating system update, the application developer has to incorporate the application with it and generate a new image. This puts the onus of ensuring security vulnerability patches and bug fixes being pushed into production on the developer as opposed to on the operations team. The operations team has traditionally more expertise to deal with such issues, so this is also a potential security hole.

The NIST guidelines identify six areas where security countermeasures should be used to combat loopholes. These include image, registry, orchestrator, container, host OS, and hardware. Image vulnerabilities can be OS vulnerabilities, possibly ones that have not been discovered yet, configuration defects, malware, untrusted images and bad security practices like storing secrets in cleartext. Images are build on top of base images, so in many cases the app developer is not aware of or responsible for issues in the underlying images. Registry-related risks can arise from insecure connections, stale images and insufficient authentication/authorization restrictions. Orchestrators that manage the container lifecycle at runtime can have bugs where network traffic is poorly isolated and allow unbounded administrative access. The latter point can arise since most orchestrators were designed without multi-user scenarios in mind and the default settings are often sub-optimal from a security perspective.

Containers can also include malicious code that can "break out" of the container and cause damage to other containers on the same host or the host itself. Uncontrolled network access from inside containers as well as insecure container runtime configurations like running in privileged mode can cause harm if the container is compromised via other means, e.g. through an application level vulnerability. Every host OS has an “attack surface” which defines the ways in which attackers can break into an OS. A compromised host translates to all the containers running on it being compromised. The use of a shared kernel between containers also increases the attack surface.

Countermeasures start from the bottom of the stack - the hardware, and go all the way up to the container runtime, as well as touching upon image and registry integrity as well as the orchestrator. Previous studies and initiatives on container security have also touched upon similar points.

Rate this Article

Adoption
Style

BT