Posted under: Research and Analysis
The explosive growth of containers is not surprising — technologies such as Docker alleviate several problems facing developers deploying applications. Developers need simple packaging, rapid deployment, reduced environmental dependencies, support for microservices, generalized management and horizontal scalability — all of which containers help provide. When a single technology enables us to address several technical problems at once, it’s very compelling. Yet this generic model of packaged services, where the environment is designed to treat each container as a “unit of service”, sharply reduces transparency and auditability (by design), and gives security pros nightmares. We run more code and run it faster, but at a loss of visibility of what’s running inside the container. It begs the question, “How can we introduce security without losing the benefits of containers?”
Containers are scaring the hell out of security pros because of their lack of transparency. The burden of securing containers falls across Development, Operations, and Security teams — but these groups are not always certain how to tackle the issues. In fact, security and development teams are not always fully aware of the security problems they face, as security is ignorant of the tools and technologies developers use, and developers don’t always know what to look for. And the problem extends beyond just containers, but the entire build, deployment and runtime environments.
The container security space has changed much since we did our initial research 18-20 months back. Security of the orchestration manager, as organization rely more heavily on tools to deploy and scale out their applications, is a big concern. We have seen a sharp increase in adoption of container services (PaaS) from various cloud vendors, which changes how you need to approach security. We ‘reached’ a little bit in our first container security paper, covering build pipleine security issues because we felt is was a hugely underservered area, but over the last 18 months the DevOps practitioners have taken note, and this has become the top inbound question. And just behind that is the need for secrets management for issuing container credentials and identity. Given the rapid change of pace in this market we felt it was time to do a refresh on the paper.
As we get a ton of calls from people moving towards — or actively engaged in — DevOps, we will gear this research both for security practitioners as well as developers and IT operations teams. We will cover some of the reasons why containers and container orchestration managers create new security concerns, and how to go about creating security controls across the entire spectrum. We will not go into great detail on how to secure apps in general here — rather we will focus on the areas of build, container management, deployment, platform, and runtime security issues that arise with the use of containers. And as always, we hope you ask questions and participatein the process. Community involvement always makes the research better and we welcome your inquires, commenst and suggestions.
*** This is a Security Bloggers Network syndicated blog from Securosis Blog authored by firstname.lastname@example.org (Securosis). Read the original post at: http://securosis.com/blog/building-a-container-security-program-2018-intro