The current wave of container-based microservice deployments is highlighting the need for new approaches to container and microservices security solutions, particularly for Docker security. Traditional security approaches aren’t appropriate for platforms/tools such as Docker and Kubernetes. To work effectively, teams who develop services require lightweight infrastructure and unobtrusive security.
Traditional service-oriented architectures (SOA) experienced many challenges, such as latency, challenges scaling up, high resource consumption associated with VMs, and lack of resiliency to recover from failures.
The past few years have seen a transition from Development and IS/IT departments into DevOps organizations, and equally, a migration from traditional microservices to container-based continuous integration (CI) and continuous delivery (CD) to Production environments.
CI and CD Best Practices:
DevOps teams containerize larger applications by functionally decomposing them into services. Then, they break each service down into a collection of microservices that each perform discrete functions. The microservices are deployed as containers onto a cluster, and are automatically scaled up or down, as needed, to meet demand. The cluster spans multiple hosts, and is also scaled up and down to meet demand.
Many tools and services have pivoted to support this new environment. Traditional security approaches don’t work in this environment. New security tools must be completely automated, built into the CI/CD workflow, and must both detect vulnerabilities at build time and protect the container environment at runtime.
Developer container security solutions could use each container’s manifest, which describes its constituent parts, to profile of how the container should interact with its environment. Furthermore, a security tool could monitor the fairly limited types of interactions microservices have, and use that as a baseline to detect unusual patterns. These two strategies are possible because deployed containers are immutable; developers create patches offline and only newly profiled containers would be able to reach production.
How Twistlock Enables This:
Twistlock integrates directly into your CI tools like Jenkins and TeamCity. It shows developers the security profile of their apps every time they build them. Critically, this happens directly in the build process, and the results appear in the same UI they’re already using. This makes the data is far more accessible and actionable than with external scanners or processes.
For every build job, you can configure Twistlock as a quality gate to ensure that only images that meet your minimum vulnerability bar are allowed to progress through the CI process. In other words, you can ensure that every image that makes it out of your CI process has had its vulnerabilities remediated according to your policy, without any security administrator having to perform manual checks:
Finally, every time you perform a build, Twistlock begins learning about the image you’ve created and building a runtime model that describes everything it should be doing at runtime – across processes, system calls, file system, and network activity. We correlate each model back to the digest of the image that was used to create it; so that every time you build your app, we’re automatically beginning to build the security model for it. We continue to enhance this model as your images progress through their lifecycle, by learning about deployment time characteristics like connected networks, and machine learning at runtime to model advanced scenarios like east/west traffic flows.
So, with Twistlock, your CI process isn’t just the beginning of your app’s life, it’s the beginning of the security model that’s created for every version you build.
Sign up for our newsletter to keep up with Twistlock container security content, or contact us for an evaluation today.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.