Fact vs. fiction: 6 myths about container security

DevOps, containers and microservices are eating software development just as software is eating the world. But with the explosive growth of these technologies and methodologies, it’s becoming increasingly difficult to separate fact from fiction. This is particularly the case when talking container security. In this article, we take a look specifically at the myths surrounding container security – and the opportunities container technology presents to integrate security at each stage of the application lifecycle that otherwise would be hard to achieve.

Myth No. 1: Containers are inherently insecure

Containers are in fact a security tool, offering more methods to secure your applications. They improve isolation for applications and provide faster, safer mechanisms for software patching vs traditional systems like VMs.

Additionally, container platforms can have certain security capabilities and processes baked in. For example, containers follow the principle of least privilege, where isolation is established by default to limit container access to required resources only. By restricting the container’s visibility into the outside world and limiting its communications with unnecessary resources, least-privilege orchestration secures both the containers and the applications.

Myth No. 2: You must purchase additional security for containers to secure your application

Before you buy additional security, examine your container solution. The question worth asking is does it enable you to bolster security across the application lifecycle? Integrated security should be an essential component of a container platform, offering protection for most use cases. You don’t want to end up seeking out budget for a separate security solution if your current container platform already meets those needs. And, you don’t want the hassle of trying to incorporate another piece of software into your tech stack that disrupts the development flow and may result in added operational overhead.

For example, most security-conscious container platforms apply seccomp profiles by default and make it easier to use Linux Security Modules and kernel security features. By using these capabilities and policies that lock down applications, you can mitigate many attacks.

If you still have concerns after leveraging all your container solution’s native security features, then considering additional security tools can be the next logical step.

Myth No. 3: I need to change my apps to get modern security

Containers accelerate application development and deployment, making security updates, upgrades, and vulnerability patches quick and easy to institute. And this is all possible without changing the underlying nature of your existing applications. You do not need to adapt your apps to special APIs, libraries or UIs.

A good example of this is how containers ease data protection using intuitive features such as encrypted overlay networks that conceal and safeguard communications between containers. To achieve these security capabilities, you don’t need to modify applications to take advantage of this default feature.

Security scanning and image signing present another example. Enterprises want security that doesn’t get in the way of development process. With security scanning and image signing, enterprises can be confident knowing that the images are verified and free from known security vulnerabilities, and that signing policies are in place that prevent untrusted content from being deployed – all in the background.

Overall, one of the greatest benefits of containers is the additional security you can add as a wrapper around an application without ever having to modify its source code. Add to this the integrated security capabilities that come with a container platform and organizations will have what they need to keep their applications secure.

Myth No. 4: All containers are the same

Not all containers are alike. This is why you need to ensure a strong security posture by using default security profiles and runtime security policies such as app armor. Make sure you’re using a container platform that takes this into account and establishes a secure container lifecycle, so you know the provenance of golden container images, which ensures a trusted base for every application you develop.

It’s important to keep in mind that trusted images are pulled from private, authenticated registries because this enables you to verify the source and security of images through certifications, signatures and security scans. By scanning your repository of golden images, you can confirm compliance with regulatory requirements and ensure the security of container images before you promote them to production.

Myth No. 5: Containers are less secure than VMs

The truth is containers done right are much more secure than VMs. Vendors and developers have designed containers to encase applications, which adds a layer of security. By contrast, VMs are based on the faulty assumption that applications could not escape the virtual environments – and did not consider the consequences if they did.

Take, for instance, read-only application environments in containers, which nullify attacks that rely on uploading backdoors, such as the Panama Papers attack. It’s much simpler to apply read-only environments with containers than with VMs. Read-only limitations fend off many of the kinds of attacks that have recently earned a lot of attention. 

Myth No. 6: Compliance is hard with containers

Compliance is easy with containers. Containers use policies that enable you to predetermine an infrastructure that you can easily audit. You can apply and review these policies across machine clusters, scaling auditing capabilities and visibility. Containers enable policy-based automation of access control rules that adhere to industry and government regulations.

It’s via these policies that organizations can enforce the security of golden images—sourcing from private repositories, scanning—regardless of scale. You can then promote containers and applications to production aligned with compliance to regulations. This approach negates human errors and the gaping vulnerabilities that would force you into noncompliance.

Moving past the myths

The notion that containers are insecure is far from the truth. Organizations want the holy grail when it comes to security – integrated security features that address each stage of the application lifecycle while at this same time ensuring that security doesn’t get in the way of developer workflows. A container platform can help achieve that goal by securing containers and applications by default, limiting access to the host system using the Linux seccomp mode and by providing added capabilities from secrets management to security scanning and role-based access control.

As more and more companies adopt container platforms, word is getting out that the technology, in fact, presents a unique opportunity to bolster security across the application lifecycle while enabling a strong governance model. It is for this reason that companies like ADP that work with sensitive and personal data use Docker Enterprise Edition to build a progressive trust workflow for their application development process.

With container platforms, companies can be assured their applications will be inherently more secure, giving them the freedom and agility to bring competitive services and applications more quickly to market.