Survey Says: Container Security (Still) Cause for Concern
The use of containers continues to grow. Whether from serverless, cloud-native apps, or a desire to modernize monoliths, containers are rapidly becoming the preferred platform for deploying apps.
Sysdig recently released its 2019 Container Usage report based on data gathered customers of its public cloud and on-premises services. The data covered over two million containers.
Aside from the really exciting (if you're me) finding that 60% of those containers are running NGINX, Sysdig uncovered some fairly troubling security stats.
Consider this one: 54% of containers lived fewer than five minutes. In 2018, that was true of only 20%.
Why is this troubling? Security, of course. If you're trying to secure access (and you should be) and trying to protect the app or API running in that container, you've got to make sure your security services are constantly adjusting policies to match the current state of the cluster. That means policies need to apply to containers when they're launched and remove policies when they decommission. That's a lot of change going on, which means a lot of operational overhead. It’s hard enough to get security right on a relatively static application. It’s really hard to do it at speed with a highly volatile one.
If that doesn't bother you, try this stat: even though 60% of container images are pulled from private registries (good job!), 52% of those fail image scans. That means they had known vulnerabilities with a severity of high or greater.
Ugh. I can't even.
It turns out that whole bunches of people are running container as root (median per host: 21) or in privileged mode (median per host: 4). Others have no restricted privileges (median 28 per host). That's particularly frustrating as Docker (the most prevalent container runtime) starts with a restricted set of capabilities by default. That means someone purposefully changed the default security settings. Running without restrictions can result in the ability to escalate privileges or breakout of the container (allowing access to the system).
We now break for a reminder on the basics of container security:
- Lock the door. Authentication is not optional. Be sure to require strong credentials and rotate them often. Use two-factor authentication whenever possible—especially for privileged access to orchestration consoles and critical infrastructure.
- Hide your valuables. Don’t inadvertently share secrets (like keys and credentials) out in the open in a repository or easily accessible, shared source.
- Screen your calls. Not all requests are valid, and some are carrying malicious code. Whether it’s an app or an infrastructure service, inspect and evaluate content for malicious intent. Optimize by consolidating the scan with SSL/TLS termination to offset the slight performance hit.
- Patch the holes. If you know an image, service, workload, or other component is vulnerable, patch it. This is especially true for vulnerabilities in externally sourced components because they are high profile targets. This is because it’s a rich field of opportunities when a vulnerability shows up in commonly deployed applications or infrastructure like Apache Struts and requires little investment by an attacker to find and exploit.
It is absolutely critical to the security of apps—and therefore the business—that good container security practices actually be put into, well, practice. Our forthcoming 2020 State of Application Services report found that cloud-native/microservices comprise on average 15% of an enterprise app portfolio. That percentage is despite findings that indicate lengthy backlogs for new applications. That means that containerized apps are only going to grow. And if we can't secure a small percentage of apps, how can we expect to scale to secure a significant percentage of them?
Practice safe containerization.
If you're interested in a refresher on container security basics, check out this series based on the expertise of my F5 colleague Jordan Zebor: