I’ve been thinking about some half-truths I’ve heard about container security in recent conversations. They center around the misconception that containers are inherently less secure than traditional virtualization. Like urban myths, they gain undeserved credibility with each retelling. By shining some light on them, I hope to dispel these myths about container security and help us focus on the real issues.  

Myth #1. An important attack vector against containers is container jailbreak

Jailbreaks are scary in theory but rare in reality. Most attack vectors are against the app. After you’ve broken into the app and own it, why bother jailbreaking? The attacker can already use the credentials and network to hop around to other interesting places. The real challenge is to recognize when an attacker owns your container and has compromised your system.

Myth #2. The issue of multi-tenancy is intriguing, and must be solved before containers are mature enough to be used in production

There are no real enterprises that are troubled by this issue. Customers who care about this typically think about it for an extra 5 seconds, and then put microservices for different applications on different VMs. And…Voilà they’re done!

Myth #3. An application firewall is a reasonable way to protect containerized workloads

Application firewalls are nearly worthless when it comes to workloads that change hosts in seconds. They’re also worthless when the payloads are encrypted. Join the two together and well, you see where I’m going. Container security needs to be truly application aware and based upon developer intent. Firewalls are operated by IT–their granularity and response time can’t help protect containerized workloads.

Myth #4. Endpoint security is a reasonable way to protect microservices

Is anyone browsing the internet from your containers? No. Endpoint security is great for your Desktop/Laptop/Mobile devices; anywhere the attacker has to fool the end user into getting infected. However, endpoint security solutions weren’t built for microservices. In fact, they’re mostly irrelevant to the attack vectors used against microservices. Endpoint security has almost no visibility into the Docker runtime and container orchestration.

Myth #5. If your images have Dockerfiles that start with FROM something:latest, they’ll always be up to date

Vulnerability management with containers isn’t as obvious or as easy as it often seems. Source images aren’t always patched in lockstep with the projects they’re created from. Even if you get the base layer up to date, you probably also have tens or hundreds of other components in your images that aren’t covered by the base layer package manager. Because the environment changes so frequently, traditional approaches to patch management are irrelevant. To stay in front of the problem you have to a) find vulnerabilities as part of the continuous integration (CI) process, and b) use quality gates to prevent the deployment of unsafe and non compliant images in the first place.

Myth#6. Container behavior can’t be analyzed for bad behavior

Container behavior can be profiled and can be whitelisted. Here’s why:

  1. Containers are declarative: The container manifest describes how it should work and interact with its environment. You can translate this information into a security profile.
  2. Containers are predictable: Developers compose container microservices from existing well-known software components. This makes it easier to baseline a container’s behavior than was the case with virtual machines.
  3. Containers are immutable: Except for patches, which take place offline, containers don’t change. If a container starts behaving differently, the cause is either configuration drift, which is bad, or a real attack.

Let us help further demystify container security. Contact us for an evaluation for your organization today!

What’s Next?

← Back to All Posts Next Post →