When you migrate to Docker, you have to take (almost) everything you know about virtual machines and throw it out the window. That’s because containers work in fundamentally different ways from virtual machines (VMs).
This also includes the security realm. Keeping containerized applications secure requires a totally different approach to, and thought process about, security. Let me explain how in this post.
The problem: Bending the rules
Previously, in the era dominated by VMs, security was all about blacklisting and restricting access to your system. It was a simpler world when you could easily identify the various components of your system and secure them using firewalls and a few rules. But problems arise when you start to make updates to your app. Those updates bring in new components, and configurations beyond the scope of pre-set rules. As a result, security teams simply enforce system-wide security defaults that aren’t touched until something breaks. This approach results in a lot of security loopholes over time.
Containers force us to think differently about security. If static rules were not enough to secure VMs, they’re all the more inadequate to secure containers. Containers are minimalist when compared to VMs. They don’t run a full OS, and they can’t be thought of as a physical machine. Containers run isolated processes and share a common host kernel. Because they operate a level higher than VMs, containers are dynamic. They are ephemeral, with much shorter lifespans than a VM. A VM is typically used for a couple of weeks or months, whereas a container is run for just 2.5 days on average.
Since they are very lightweight and short-lived, containers essentially fragment the security process for the better. They take outdated system-wide security policies and allow us to break those policies down into manageable chunks.
Setting security policies at the process level—not the system level—may sound like a lot more work, and it is more complex, but the benefit of securing your app in a way that wasn’t possible before is worth the effort. The key is to find the best way to manage this decentralized security model.
Because of how lightweight they are, it’s easy to create and destroy containers at the speed of thought. When you have a new upgrade for your app, you deploy it into a VM and keep the same VM running. But with containers, you can package your artifacts in a container, and deploy the same container into production that you used for development. Containers are immutable—They stay the same across the application lifecycle.
The implication of this is that rather than using a static security profile that is outdated after the next upgrade, you can define a new security profile that’s specific to each version of the app. Again, this may sound tedious, especially considering the pace of releases in a microservices application, but the key is to find an automated, scalable way to define security profiles.
Security defaults aren’t enough
Though Docker and other container tools have default security features, there are too many moving parts to the container stack, and none of those tools are extensive enough to cover it all. For example, IaaS providers like AWS include default security features along with their container registry (ECR). But these are either user-centric, focusing on the default IAM features of the AWS platform, or they are host-centric, where they use the same protocols that are used to secure cloud-based VM instances.
These approaches may work to monitor and secure one tool, but they don’t cover the entire toolchain that’s used in a container workflow. Implementing the kind of dynamic security policies that containers demand takes a purpose-built security tool.
Containers need a purpose-built security tool
A dedicated security tool that’s built for containers should enable the kind of dynamic security policies that containers require. As containers are created and modified at a rapid pace, the tool should be able to keep pace with every change—not just from a reporting and monitoring perspective, but even enforcing rules automatically. It should be able to gauge the impact of changes and take action without requiring human intervention at every point. Advanced machine learning algorithms enable this level of intelligence.
Organizations that understand the differences between the traditional and modern paradigm of security will get the most out of their containerized apps in production. Static rules that worked for VMs won’t work for minimalist and immutable containers. Neither will the defaults of registries and Docker. What’s needed is a dynamic approach to security, and a purpose-built tool that provides end-to-end visibility and control of your containerized application.
Want more details on VMs VS containers? We’ve got you covered. For more info on the new paradigm of container-based security, download our white paper on the proactive security movement, or get details on how to migrate from VMs to containers here.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Istio Visualization, Security, and Compliance Checks with TwistlockRead the Blog
Protecting Serverless Functions at Runtime: Serverless Defender v2Read the Blog
Cloud Platform Discovery: Identifying All Your Cloud Native ServicesRead the Blog
Using Twistlock to Secure Workloads on Pivotal Cloud FoundryRead the Blog
Twistlock, Azure Container Instances, and AKS virtual nodesRead the Blog