Reading Time: 3 minutes

Containers are increasing in numbers every day and seem to be everywhere, as organizations are eager to reap the many benefits offered by them such as an agile application development and deployment across all platforms.

Many also believe that using containers can help them minimize security constraints because of their short-life nature. Is this true or just another misperception?

Although containers do not have inherent insecurities, they are often being deployed in a non-secure manner, resulting in numerous security challenges.

Security challenges when deploying containers

The sheer number, versatility, and ephemeral state of deployed containers plus the fact that containers must communicate with other entities, lead to organizations not having the ability to own adequate inter-container traffic visibility.

Thanks to this lack of visibility, containers are oftentimes forgotten, and intrusion prevention measures and security controls become ineffective, increasing the attack surface and therefore the overall business risk. Additionally, the shortage of visibility may result in a scarcity of accountability as containers transverse different environments from development to production.

Another security challenge related to containers is poor vulnerability management. For instance, when cloning existing images to make new containers, their vulnerabilities also will be replicated.

This highlights the necessity for security to be an integral part of organizational container strategy. Otherwise, configuration errors and missing patches may be the reason for unauthorized images being deployed and executed in production environments leading to increased attack surface and more successful attacks.

Finally, since containers use a shared OS kernel, a compromise of the host OS kernel by a rogue container may lead to a loss of access to all or any running containers on the host likewise as potentially other hosts on the network.

How to secure your containers

Maybe the best practice for securing your containerized environment is acknowledging the necessity of doing so. Except for this foundational concept, there is some good advice to follow to effectively secure your containers.

Have visibility into your containers

Before deploying a container, make sure you understand its dependencies and what is included therein. To ensure that your container images are pristine, you must gain visibility at every stage from development to production.

Not trusting a container’s software is a great starting point. You must check it very thoroughly to understand “where they come from, how they were produced, and their corresponding sources,” as Dirk Hohndel, vice president at VMware, pointed out at the 2019 Open Source Leadership Summit.

In a nutshell, double-check your containers’ contents before deploying them and never run a container with unknown or obsolete software. Just because a container image claims to contain the latest and greatest programs and libraries, that doesn’t mean it actually does.

One way to mitigate this problem is to use applications that can help you clean up your containers. Although I don’t like reinventing the wheel, maybe the best approach is to stop using other people’s container images.

If you, just like Hercules, take the harder road of Virtue and start building your own container images, you will have a much better understanding of what’s going on within the containers, which has benefits beyond security.

Control root access

Most containers are built with root access by default. However, this is a questionable practice. Although it is easier for developers to run containers as root, there are enormous risks with root access.

There are several approaches to handle this issue. One way is to ascertain a corporate policy that no containers are ever allowed to run as root. An alternative way is to exercise the least privilege principle. You can specify a non-root user within the Dockerfile, when you create a container image, to run the container as that specific user with the minimum required system access.

Finally, you can also use user namespace when running privileged container processes to assist secure containers. With this method, the UID for running these processes within the container is zero (which is the root), but outside the container the UID is the unprivileged 1000.

Check the container runtime

The National Institute of Standards and Technology’s (NIST) SP 800-190 “Application Container Security Guide” points out that container runtimes are also vulnerable to attacks. Although this is not a common security gap, NIST points out that container runtime security vulnerabilities can be “particularly dangerous,” if they allow scenarios in which malicious software can attack resources in other containers and the host OS itself.

An attacker may also be able to exploit vulnerabilities to compromise the runtime software itself, and then alter that software so it allows the attacker to access other containers, monitor container-to-container communications, etc.

Security problems are far more common with runtime configurations. Container runtimes typically expose many configurable options. Setting them improperly can lower the relative security of the system.

For example, on Linux container hosts, the set of allowed system calls is often limited by default to only those required for safe operation of containers. If this list is widened, it may expose containers and the host OS to increased risk from a compromised container.

Similarly, if a container is run in privileged mode, it has access to all the devices on the host, allowing it to essentially act as part of the host OS and impact all other containers running on it.

Another example of an insecure runtime configuration is allowing containers to mount sensitive directories on the host. If a compromised container can make changes to these paths, it could be used to elevate privileges and attack the host itself as well as other containers running on the host.

Harden the operating system

NIST also recommends running a container-specific operating system because the threats are typically more minimal since the OSs are specifically designed to host containers and have other services and functionality disabled.

Further, because these optimized OSs are designed specifically for hosting containers, they typically feature read-only file systems and employ other hardening practices by default. Whenever possible, organizations should use these minimalistic OSs to reduce their attack surfaces and mitigate the typical risks and hardening activities associated with general-purpose OSs.

Organizations that cannot use a container-specific OS should follow the guidance in NIST SP 800-123, Guide to General Server Security to reduce the attack surface of their hosts as much as possible.

For example, hosts that run containers should only run containers and not run other apps, like a web server or database, outside of containers. The host OS should not run unnecessary system services, such as a print spooler, that increases its attack surface.

Finally, hosts should be continuously scanned for vulnerabilities and updates applied quickly, not just to the container runtime but also to lower-level components such as the kernel that containers rely upon for secure, compartmentalized operation.

Container security is a top priority

With more and more businesses adopting and deploying containers, their security is becoming a top business priority. According to a recent survey, 94% of the respondents have experienced a security incident in their container environments. This only highlights how important it is to get container security right to protect your business and your customers.

How useful was this post?

Click on a star to rate it!

No votes so far! Be the first to rate this post.

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?

We'll never share your email with anyone else.