Thirteen Ways Containers are More Secure than Virtual Machines
Last year, conventional wisdom had it that containers were much less secure than virtual machines (VMs)! Why? Because it was easier to break out of the container abstraction layer, which is arguably weaker than VM abstractions supported by hardware VT-x optimization. Once broken loose, malicious code could easily attack the host. Even worse, once the host is compromised, the containers lack their own operating system barriers leaving them basically undefended. Since containers have such thin separating walls; it was easy to paint these back door risks with a broad brush.
Here’s a reality check: Front door attacks and unpatched vulnerabilities are much more likely than these backdoor hacks.
The proliferation of uniquely configured VMs running bloated operating systems with inconsistent security practices is our primary security concern. In fact, light-by-design container configurations tend to have much less attack surface and the thin walls actually make it easier to enhance security before and after deployment.
Without any inherent technical advantage, containers are more secure in at least six ways I can easily describe:
- No ssh enabled into containers: This takes away the front door for most attacks.
- No user access expected: No users eliminates the need for credentials or tools to support users.
- Container systems restrict ports by default: Since containers are services, we are generally more specific and limiting about which ports to connect.
- Short-lived containers are unlikely bases for attackers: It’s hard to hop through a system that may only be around for minutes or even seconds.
- Immutable designs make it difficult to inject malware: We don’t persist application areas of the file systems in containers so they don’t retain injected programs.
- Automatic generation makes it faster to pick up and promote security patches: With automated build from CI/CD pipelines, updating code and libraries into production can happen very quickly without manual effort.
Moreover, best practices around containers are offering additional safeguards:
- Pre-deploy sources and dependency validation: These services check containers to make sure that they are using valid and expected code paths.
- Pre-deploy authenticity validation: Taking the above checks another step, we can ensure chain of trust on containers to ensure that the code has not been tampered with.
- Pre-deploy image scanning for vulnerabilities: Even better, these services automatically evaluate containers for known issues by looking for signatures of compromised packages.
- Active vulnerability scans of running containers: Once deployed, services external to the container can watch containers for intrusions and halt or intercept attacks.
- Network routing that includes traffic inspection: Since network routing is so fundamental in container orchestration, it makes sense to include a layer of security into those services to effectively create a function based service firewall.
- Integrated log capture: Since there’s no local storage, most container patterns are including central log capture and analysis as a first class citizen. This makes log analysis much easier.
- External injection of trust and credentials: The service pattern for containers does not allow injecting credentials in the container or code. This means that we are building trust systems based on giving credentials just-in-time to running live instances rather than static code.
That’s a lot of ways that containers will emerge as more secure than current VM image based models! The primary new non-VM benefit is the use of containers’ thin walls to provide cross-cutting security and other services at the host level. It should not be surprising to advanced users that most of the improvements come from strong architecture patterns that are required for container services. The market for these services is just beginning.
Feature image via Pixabay.
