Apps hosted in virtual machines (VMs) are relatively simple in terms of security. You treat VMs like a physical device. Install antivirus software, ensure passwords are strong, keep the VM updated, and your app is secure–for the most part.
With containerization, however, there are many new layers added to the stack. You can’t treat containers as physical machines. They’re fundamentally different from VMs. For this reason, you need a completely different approach to application security.
Following are some tips and best practices for ensuring that your transition from VMs to containers is secure:
- Decentralize resource allocation
Unlike VMs which are isolated at the hardware level, containers are isolated at the process level. While each VM has its own kernel, containers share the same host kernel. Initially, this was seen by some as an inherent weakness in the container model, as a compromised container can affect the host, and in turn, other containers running on the host. Today, rather than a weakness, this is an opportunity to secure applications in a way that wasn’t possible before.
With containers, you set limits on the resources each process can utilize. This includes limits for CPU, memory, and disk I/O. However, you’re not dealing with one or even a couple of VMs—In this case, you’re dealing with tens or hundreds of containers. While it can be a nightmare to set limits for every container individually, if you can handle resource allocation at scale, it gives you a lot of control over the security of your app. Rather than having blanket blacklists and restrictions at the VM level, you have more control at the process level. This helps reduce the surface area of an attack, and brings deeper visibility across the system.
- Scan container images for vulnerabilities
Containers encourage collaboration, which is the central idea behind DevOps. They can be shared internally within an organization, or externally with the world. To share container images, they need to be hosted in a registry like Docker Hub, or AWS ECR (EC2 Container Registry). Downloading container image repositories from a registry is central to the Docker experience, and is unlike anything in the VM world. However, public container images bring new security challenges as well.
Every image that’s downloaded needs to be scanned for vulnerabilities. Most registries provide a default scan of all images downloaded. Docker’s own Security Scanning is nice to have, but you need a way to customize scanning to suit your needs. And you need powerful alert mechanisms to know when something goes wrong.
- Secure your orchestrator
With more containers making it to production environments, and the need for powerful container management, orchestrators have emerged as a central component of the container stack. Kubernetes leads the pack, joined by Docker Swarm and Mesosphere DC/OS. Unlike VMs which had proprietary management tools as part of the VMware console, orchestrators are powerful standalone tools. They do more than just create new nodes. They are responsible for rollbacks, managing storage, service discovery, and failover.
While orchestrators have some basic security defaults, they are meant to be powerful automation tools. This means they need to be deliberately secured at every point to be truly production-ready. And with the changing landscape of orchestrators and container tooling, security needs to be tool-agnostic so you can enforce the same levels of security irrespective of which tool you may use today, or in the future.
- Build security that scales
With added complexity at every level (infrastructure resources, registries, and orchestrators), container security is challenging. The way to think about security in a containerized world is to enforce scalable security practices or models. This way, whether you manage a few processes or several, and whether you use Kubernetes or Docker Swarm, your security model will adapt to your changing application stack.
A scalable security model requires automation. With VMs, a developer would define the various components of the app to IT, who would figure out how to secure each component. But with containers, any description of an app will go out of date immediately. This means IT needs a way to automatically tag new nodes as they are created. As changes are made, they should be tracked and responded to in an automated way. This requires more than just a smart IT team—It needs the power of machine learning algorithms that can detect changes and make decisions without human intervention. Container security requires this unique combination of a scalable security model, enabled by intelligent monitoring tools like Twistlock.
In summary, containers change everything about the application stack, especially security. While it brings complexity and may seem like a step back, in reality, if you take a different approach to container security, it is a tremendous opportunity for positive change. Container security requires a scalable and automated security model, and intelligent monitoring tools that can execute on this security model.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
AWS Fargate Security: Runtime Defense with Twistlock 2.5Read the Blog
Cloud Native Forensics: Security Incident Response in Twistlock 2.5Read the Blog
Announcing Twistlock 2.5: GA Release NotesRead the Blog
GitOps 101: What Is GitOps, and Why Would You Use It?Read the Blog
DevSecOps Learning Resources: How to Learn to Do DevSecOpsRead the Blog