By Henrik Rosendahl
What are the arguments for containers vs virtual machines (VM’s)? Back in March 2016 Mike Coleman (@mikegcoleman) from Docker wrote a blog post titled: Containers Are Not VMs. Mike and I used to be colleagues at VMware EUC – working on delivering applications in virtual desktop environments.
As you probably already know Virtual Machines provide a very strong isolation on the host level and don’t share the OS. The primary reason for developers to move to a microservices based architecture is to break up the app stack into smaller pieces, thus providing a more agile environment. In doing so your application services will now be connected thru the network and this opens up a myriad a potential security issues.
Let’s continue Mike’s house (vm) vs. apartment building (Docker host) analogy from this blog post. You can choose to protect your single family house (vm) as much as required and desired and just because your next door neighbor is careless it doesn’t affect you much. Ok, if there’s a fire that might affect you, but rarely.
However, if you live in an apartment building (docker host) – the kind where there’s a shared lobby and shared hallway access to doors — your protection against thieves is only as good as your neighbor’s behavior. What if he leaves the balcony door wide open for the day? You can lock your front door when you leave the apartment – isn’t that good enough you ask? Well unfortunately Docker by default requires you to leave your front door wide open by design because legitimate visitors may need to get in. But if thieves get access to your neighbor’s apartment it’s a walk in the park to get into yours.
Before we get into the security issues with containers, let me point out that some people believe that containers are inherently more secure than vm’s. The argument is that breaking applications into microservices with well-defined interfaces and limited packaged services reduces the attack surface overall. The key point is that a well-implemented container deployment which includes security precautions can be at least as secure, if not more secure, than vm’s.
Let’s strike a more serious tone and look into some technical aspects of the Docker host and how it differs from VMs from a security perspective.
Containers and container deployments face a multitude of different threats, weaknesses and vulnerabilities, which must be considered, and dealt with prior to production. Unlike VMs, the fundamental risks of open network traffic across services and a shared kernel cannot be ignored and deserves real security concern.
Recommendations can be made for any container platform, and in almost any deployment scenario. They generally come down to similar security recommendations for almost any system, platform or service:
- Scan your container before and during run-time. Reduce all attack surfaces in the App/OS etc. to only those required and harden what surfaces must be exposed.
- Use network micro segmentation to isolate application clusters based on trust, risk, and exposure.
- Apply and enable all security relevant and supported configuration options for the platform such as registry scanning, access controls, and container privileges.
- Always keep the host and container versions up-to-date.
- Know your app and how it’s supposed to behave. Create visibility to the intra-container and intra-host network traffic (east-west) as well as normal north-south monitoring.
- Continuously test and review the above security recommendations in your CI/CD process.
- Log threats and vulnerabilities from your Docker host in your regular SIEM tool such as Splunk or Nagios
- Implement a third party – container specific security platform such as NeuVector. Remember traditional firewalls can’t keep up with the rapid pace and fluidity of container deployments so status quo is not an option.
Today, security is much more of a concern with containers than it is with virtual machines. In fact, according to a Forrestor Research study, 53% of enterprises deploying containers cite Security as top concern.
This is likely due to the fact that vm’s have reached maturity in their deployment and the attack surfaces are fairly well understood. Containers, on the other hand, are the wild west and no one really knows where attacks could come from.
What About VMs AND Containers?
Many enterprises with existing applications running on a stable vm infrastructure are choosing to take a ‘toe in the water’ approach. By deploying containers on vm’s they get the benefits of mature monitoring and isolation with more rapid DevOps processes. Compared to containers running on bare metal, they do give up some performance, scalability, and cost. But it’s certainly a valid way to transition.
It’s easy to get excited about this new microservice era and all it’s clear benefits. However with all new technologies come new threats that MUST be considered and understood prior to production. At NeuVector we believe that the best protection for containers happens during run-time and as close to container network traffic as possible.
It’s the last line of defense in a new and often changing environment.
Analogously – if it was at all practical and affordable every apartment building would have it’s own doorman and check all visitors ID – right?