Containers and Cloud Security: Threats and How to Manage Them

David Christian

The biggest cloud security threat to containerized applications is security teams believing that simply issuing decrees to over-stressed developers (who rarely understand the intent or logic of those policies) will be effective. This approach hasn’t worked for bare-metal servers or virtual machines, and it is magical thinking to believe this approach will work for containers. Compounding the issue is that many security team members have never been active participants on agile development teams, so the cultural and experiential gap is wide. Application teams will pay lip service to these decrees, and a few items of the low-hanging fruit variety will be resolved, but usually the edicts will be acknowledged but largely unheeded.

As a general rule for any piece of IT infrastructure, the default security configurations simply aren’t enough. While I’m certain that the people who designed these defaults did so as a starting point, many engineers view them as the end game. Internet-to-cloud network, service and instance integration into cloud network, host OS-to-container integration, software components, and their credentials in the container layers are all part of the security equation – and no one singular vendor or project controls them all. Yet they must be made to be rational, understandable and secure at every step, and continually refined as the computing landscape inevitably changes.

The connection between the host OS and the guest OS are the most helpful of the “default” configurations, and they’re also a great example of what a moving target these defaults can be. When the container engine Docker was first released, the container user had to be root. This was obviously not ideal, but it was the only way one could make it work and gain a security advantage. The Docker folks corrected this by allowing containers to be managed by a nonroot user, but what if you still have a Docker configuration from those days? The Docker user must be limited in what it can access at the OS level — just enough to do the job. This is difficult enough in a public cloud, and in private clouds it can raise concerns to a whole other level, because of the lack of APIs.

And there are plenty of other security issues to consider. For example:

• Controlling your network via software, so when the inevitable concerns come to light, they can be rapidly refactored.
• Management of identity and access management (IAM). When you are breached, can you explain how the breach was limited to what your bad code or misconfiguration was limited to, or was literally everything at risk?
• Maintaining a solid game plan to securing cloud machine images. Do you know when a long-running instance has fallen out of policy? When you discover a problem Instance, what do you do then? Is the instance sufficiently automated to repair the issue? Is your environment sufficiently automated to do a simple replacement?
• Container monitoring and updating mechanisms. Containers can become fossilized very quickly. This is especially true if there is no continuous Integration and continuous delivery (CICD) chain to either pull from GitHub or DockerHub to keep the base container(s) up to date, along with multiple scanning tools to find defects.
• Flexible and routinely updated policies (and enforcement!) Overly stringent decrees intended to protect your environment mean, in reality, that imported software becomes old and is rarely updated.

The Solutions

The following steps can help address these concerns:

DevSecOps: It is critical that security teams contribute code or, at the very least, engage in true discourse with development teams. Some organizations have figured this out and that is why there is a DevSecOps movement. The reality is that security is just another set of features, and if the security team can’t or won’t contribute, only those features …