BT

Your opinion matters! Please fill in the InfoQ Survey!

NIST Publishes Guidelines on Application Container Security

| by Hrishikesh Barua Follow 5 Followers on Dec 04, 2017. Estimated reading time: 3 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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 Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT