Containers offer a logical packaging mechanism for abstracting applications from the environment they run in. This decoupling allows for easy and consistent deployment of container-based applications, regardless of whether the target environment is a private data center, the public cloud, or even the developer’s laptop. Containerization allows development teams to move quickly, effectively deploy software, and operate on an unprecedented scale. Containers take off in popularity and use, as a strategy. The container virtualization market will quadruple in size by 2021, according to data from the 451 Research Company. Yet as with so many new technologies, containers have not been designed or architectured with safety in mind.
This article will take a closer look at some common security issues with containers, why they exist, and how you can overcome them.
1. Using insecure images:
Containers are build either using a parent image or a base image. These images are quite useful for building containers because you can reuse the different components of an image rather than buiding a container from scratch. However, like any other piece of code, images or their dependencies might contain vulnerabilities.
The security of the image begins with the implementation of strict vulnerabilities scanning practices and policy on image provenance. Try using a policy that would refuse to use images if it has not been scanned in the last 60 days or if it comes from a non-whitelisted image registry.
2. Containers with privileged flag
Anybody with even a limited knowledge of containers might be aware of what a privileged container is. Containers running with a privileged flag can do just about anything a host can do, run with all the capabilities, and gain access to the host’s device. That means they can wreak havoc if a hacker breaches a container running with the privileged flag.
We would like to advice you that avoid such flags while running containers. However, you can use CAP ADD and CAP DOP to add finer-grained capabilities to your container.
3. Unrestricted communication among containers
Containers need to communicate with each other to achieve their goals. Because of the number of containers and microservices, you may be running, and the ephemeral nature of containers, in general, can be a challenge to implement networking / firewalling rules in adherence to the least privilege principle. Nonetheless, your goal should be to allow containers to communicate only to those containers that are absolutely necessary to minimize the surface of your attack.
Container orchestration and management software like Kubernetes are a perfect way to bring network controls into operation. For example, Kubernetes packages containers into Pods and enables DevOps teams to implement networking policies that may restrict Pod-to-Pod communication to what’s required. This can be done by first observing the application ‘s behavior to determine which communication paths are necessary for the application to work, and then creating network policies that are essentially whitelisted for those networking pathways.
4. Running malicious and rogue processes in containers.
Monitoring running container processes in a sprawling environment with a container having an average lifespan of hours or even minutes can be particularly challenging. In other words, the rapid churn of containers makes it almost impossible for mere mortals to monitor at any given time what container processes are running, let alone to identify unnecessary or malicious processes.
Instead of waiting for a successful breach to notify you that there was a malicious process going on in a container and hampering container security, limit the number and types of operation that can be run. This risk can be mitigated in two ways. You can use the CAP ADD feature of Docker to only add those Linux capabilities that a container needs to run properly and achieve its goal, and use CAP DROP to remove all unnecessary capabilities.
You can also set PID limits as an additional mitigation step so that you limit your container only to run a set number of processes consistent with what the container needs to achieve its goal. This will prevent fork bombs and prevent the running of malicious processes such as reverse shells and remote code injections.
Read Next: Top 5 Hybrid Cloud Options Available In 2020
5. Containers which are not appropriately isolated from the host
When it comes to container safety, it is a double-edged sword. Combined with their short life span and restricted flexibility, their immutable nature provides many security benefits. However, containers can also be a vector used to attack the underlying host. We mentioned earlier that this risk is posed by containers operating the privileged flag. Many other misconfigurations could threaten the underlying host.
Here are a few steps that you can take to isolate containers from the host further. Here are only two examples:
- Never share the host’s network namespace. Doing so could put you at risk of shutting down the Docker host from a container.
- Never share the host’s process namespace. Doing so would allow a container to see all the processes running on a host system, leaving the host’s processes in danger of being manipulated or shut down.
Due to containers, microservices and DevOps come into the limelight, resulting in faster development and release cycles. They’ve brought developers and security teams more closer. Proper securing of containers involves following known security best practices and ensuring that security is embedded in the container’s life cycle instead of being treated as an afterthought.