A two-part blog series on considerations for keeping container use secure.
Containers are great
With good reason, we hear a lot about how containers allow developers to take advantage of faster application development and give them the ability to scale. Why does this matter? As my colleague Katey Wood recently noted, containers break applications into more manageable pieces, microservices, for more efficient software development that gets new applications and features into the hands of users and customers quickly.
...when properly secured
However, that means applications broken into pieces expand the attack surface. No matter how secure containerized systems claim to be, attackers are still looking for new ways to exploit them. Why? Business applications that handle sensitive data or data protected by compliance mandates are often run on containers.
Technology leaders need to be assured of the security viability of containers before they move en-masse to container deployment.
This being the case, this blog post will look at some of the security challenges that containers may pose, and in a second post, I'll outline best practice security considerations for containers.
Containers accelerate application development and deployment processes, making security updates, upgrades, and vulnerability patching easier. Yet the speed of deployment can be a challenge too. Specifically, this speed of deployment means that companies may not be able to go through compliance testing which always seems to come back to bite security teams at some point.
With the need to split applications and/or data across microservices, companies now have many services and ports to keep track of and secure. Given how fast containers come and go, it is difficult to know what containers are running—and what related services or ports may be vulnerable.
Like all software, containers are created by humans and will have exploitable flaws. We have seen a number of container-related CVEs over the past few years. There have been proof of concepts published for container escapes. Basic container misconfigurations have inadvertently exposed containers to the internet.
To date, we have seen attacks in environments without containers—and with the increased attack surface that containers bring, we must secure accordingly.
In a flat network, the default policy is to allow all devices to talk to all other devices. Flat networks make applications deployed through containers vulnerable to east-west type attacks (where the only security is at the perimeter, which is north-south). Attacks can come from 'within' the network, spreading due to very loose segmentation and access controls between containers, leaving production environments vulnerable.
Containers, when not secured properly, can indeed increase security risk in an enterprise. We often see container security tacked on top of the existing segmentation products, adding cost and complexity to the overall security solution.
We have outlined security risks and challenges that threaten successful container deployments. In our follow-on post, we’ll examine guidance on how to consider container security – from code to containment.