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
Your storage system should be locked down with all security and access control tools available to you as well. That is true whether the storage serves containers or any other type of application environment.
How do you secure containers? That may sound like a simple question, but it actually has a six- or seven-part answer.
That’s because securing containers doesn’t involve just deploying one tool or paying careful attention to one area where vulnerabilities can exist. Because a containerized software stack involves so many different components, you need to secure many different layers. The tools designed to help you harden one part of your environment won’t protect other segments.
Commercial security tools do exist, and are designed to provide relatively comprehensive security or container environments. They are good tools, and they can certainly be useful parts of a container security strategy, but they have their limitations. To be truly secure, you need to analyze each of the layers in your stack, and be sure that they are covered adequately by the security tools or processes you put in place.
This post helps you plan a complete container security strategy by outlining all of the layers you need to secure, and explaining the primary considerations to keep in mind when securing each one. Read more
MongoDB, the popular open source NoSQL database, has been in the news a lot recently—and not for reasons that are good for MongoDB admins. Early this year, reports began appearing of MongoDB databases being “taken hostage” by attackers who delete all of the data stored inside the databases, then demand ransoms to restore it.
Security is always important, no matter which type of database you’re using. But the recent spate of MongoDB attacks makes it especially crucial to secure any MongoDB databases that you may use as part of your container stack.
This article explains what you need to know to keep MongoDB secure when it is running as a container. We’ll go over how to close the vulnerability behind the recent ransomware attacks using a MongoDB container while the container is running—as well as how to modify a MongoDB Dockerfile to change the default behavior permanently. Read more
As one of the most disruptive technologies in recent years, container-based applications are rapidly gaining traction as a platform on which to launch applications. But as with any new technology, the security of containers in all stages of the software lifecycle must be our highest priority. This post seeks to identify some of the inherent security challenges you’ll encounter with a container environment, and suggests base elements for a security plan to mitigate those vulnerabilities.
Benefits of a Container Environment and the Vulnerabilities They Expose
Before we investigate what aspects of your container infrastructure will need to be covered by your security plan, it would be wise to identify what potential security problems running applications in such an environment will present. The easiest way to do this is to contrast a typical virtual machine (VM) environment with that in use for a typical container-based architecture. Read more
Rancher is a complete container management solution, and to be a complete platform, we’ve placed careful consideration into how we handle networking between containers on our platform. So today, we’re posting a quick example to illustrate how networking in Rancher works. While Rancher can be deployed on a single node, or scaled to thousands of nodes, in this walkthrough, we’ll use just a handful of hosts and containers.
Setting up and Launching a Containerized Application
Our first task is to set up our infrastructure, and for this exercise, we’ll use AWS. Let’s deploy a master node in EC2, install Docker, and start Rancher with the following command:
The Rancher server is now available at 22.214.171.124:8080(note: these IP addresses are released to the public once these AWS instances are destroyed. Here, these IP addresses are for reference only). Through the EC2 console, we’ll also add two hosts, H1 and H2, on which application containers will run. Here’s a logical setup of the topology so far: one of the nodes is running the Rancher server software, and the rest are running the Rancher agent: