Container security was initially a big obstacle to many organizations in adopting Docker. However, that has changed over the past year, as many open source projects, startups, cloud vendors, and even Docker itself have stepped up to the challenge by creating new solutions for hardening Docker environments. Today, there is a wide range of security tools that cater to every aspect of the container lifecycle.
Docker security tools fall into these categories:
Kernel security tools: These tools have their origins in the work of the open source Linux community. They have been inherited by container systems like Docker as foundational security tools at the kernel level.
Image scanning tools: Docker Hub is the most popular container registry, but there are many others, too. Most registries now have solutions for scanning container images for known vulnerabilities.
Orchestration security tools: Kubernetes and Docker Swarm are the two most popular orchestrators, and their security features have been gaining strength over the past year.
Network security tools: In a distributed system powered by containers, the network is more important than ever. Policy-based network security is gaining prominence over perimeter-based firewalls.
Security benchmark tools: The Center for Internet Security (CIS) has provided guidelines for container security, which have been adopted by Docker Bench and similar benchmark security tools.
Security with CaaS platforms: AWS ECS, GKE and other CaaS platforms build on the security features of their parent IaaS platform, and then add container-specific features or borrow security features from Docker or Kubernetes.
Purpose-built container security tools: This is the most advanced option for container security. In it, machine learning takes center stage as these tools look to build an intelligent solution to container security.
Here’s a cheatsheet of Docker security tools available as of mid-2017. It’s organized according to which part of the Docker stack the tool secures.
In the world of containers, Kubernetes has become the community standard for container orchestration and management. But there are some basic elements surrounding networking that need to be considered as applications are built to ensure that full multi-cloud capabilities can be leveraged.
The Basics of Kubernetes Networking: Pods
The basic unit of management inside Kubernetes is not a container—It is called a pod. A pod is simply one or more containers that are deployed as a unit. Often, they are a single functional endpoint used as part of a service offering.
Two examples of valid pods are:
Database pod—a single MySQL container
Web pod—an instance of Python in one container and Redis in a second container
Useful things to know about pods:
They share resources—including the network stack and namespace.
A pod is assigned a single IP which clients connect to.
A pod configuration defines any public ports and what container hosts the port.
All containers within a pod can interact over any port over the network. (They are all referenced as localhost, so be sure that all the services in the pod have unique ports.)
A Kubernetes service is where multiple identical pods are managed behind a load balancer. Clients connect to the IP of the load balancer instead of the individual IPs of each pod. Defining your application as a service allows Kubernetes to scale the number of pods based on the rules defined, and available resources.
Defining an application as part of a service is the only way to make it available to clients outside of the Kubernetes infrastructure. Even if you never scale past one node, services is the avenue to have an external IP address assigned.
Cyber security is no longer a luxury. If you need a reminder of that, just take a look at the seemingly endless number of stories appearing in the news lately about things like malware and security breaches.
If you manage a Docker environment, and you want to help make sure your organization or users are not mentioned in the news stories that accompany the next big breach, you should know the tools available to you for helping to secure the Docker stack, and put them to work. This post identifies the Docker security tools available (both native ones from Docker itself and third-party options) that can help to secure your Docker containers.
Each time a new software technology arrives on the scene, InfoSec teams can get a little anxious. And why shouldn’t they? Their job is to assess and mitigate risk – and new software introduces unknown variables that equate to additional risk for the enterprise. It’s a tough job to make judgments about new, evolving, and complex technologies; that these teams approach unknown, new technologies with skepticism should be appreciated.
This article is an appeal to the InfoSec people of the world to be optimistic when it comes to containers, as containers come with some inherent security advantages:
Managing containers requires a broad scope from application development, test, and system OS preparation, and as a result, securing containers can be a broad topic with many separate areas. Taking a layered security approach works just as well for containers as it does for any IT infrastructure.
There are many precautions that should be taken before running containers in production.* These include:
Hardening, scanning and signing images
Implementing access controls through management tools
Enable/switch settings to only use secured communication protocols
Use your own digital signatures
Securing the host, platforms and Docker by hardening, scanning and locking down versions
*Download “15 Tips for Container Security” for a more detailed explanation
But at the end of the day, containers need to run in a production environment where constant vigilance is required to keep them secure. No matter how many precautions and controls have been put in place prior to running in production, there is always the risk that a hacker may get through or a malware might try to spread from an internal network. With the breaking of applications into microservices, internal ‘east-west’ traffic increases dramatically and it becomes more difficult to monitor and secure traffic. Recent examples include the ransomware attacks which can exploit thousands of MongoDB or ElasticSearch servers, include containers, with very simple attack scripts. It’s often reported that some serious data leakage or damage also has happened from an internal malicious laptop or desktop.
What is ‘Run-Time Container Security’?
Run-time container security focuses on monitoring and securing containers running in a production environment. This includes container and host processes, system calls, and most importantly, network connections. Read more
As a relatively new technology, Docker containers may seem like a risk when it comes to security — and it’s true that, in some ways, Docker creates new security challenges. But if implemented in a secure way, containers can actually help to make your entire environment more secure overall than it would be if you stuck with legacy infrastructure technologies.
This article builds on existing container security resources, like Security for your Container, to explain how a secured containerized environment can harden your entire infrastructure against attack.
Some Background on Container Security
When you’re thinking about containers and security, it’s always good to have some history on why containers work the way they do and what that means for security. Aqua Security, one of the firms that specializes in container security, offers A Brief History of Containers to provide some context.
As is visible in the evolution from chroot to Docker and the Open Container Initiative, it is obvious that isolation between services coexisting on shared servers was always the leading goal—not necessarily well thought-out, hardened security practices. Isolation is a good counter-measure, but, as shown in this Security for your Container article, there are a lot more things that can and should be done.
Here are three examples of easy first steps that can be taken use containers to make your environment more secure: Read more