
A Security Reminder: Containers Talk to Each Other and Other Endpoints
by Anastasios Arampatzis
Containers have changed the way we ship goods globally. Over 60 years ago, Malcolm McLean debuted the world’s first ship for carrying trailer-sized containers, dramatically speeding up the method.
Just as containers changed the shipping industry, containerized applications are changing how businesses build and deploy software. According to a recent Gartner report, “by 2023, more than 70% of global organizations will be running more than two containerized applications in production, up from less than 20% in 2019.”
Containers’ adoption has made container security a critical consideration for organizations using them for application development. A compromised container with heightened privileges can threaten all other containers in addition to the underlying host, much like a thief who breaks into a physical container where the keys to the locked doors of all other containers are stored. Provided that containers are more complex than virtual machines, learning how to secure containers is extremely important.
Security risks and challenges
When businesses were using virtual machines to host applications, security was as simple as these machines. You needn’t have to worry about APIs, overlay networks or software-defined storage configurations, because hardening these virtual environments was about securing the host environment and the application.
Container security presents more challenges because the environment is complex. As an example, you will have multiple images hosting microservices or multiple instances of the same image running at a given time.
An important feature of containers is their need to talk to each other, as well as to other entities to function properly. If a container is breached, the ability for a malicious actor to move laterally within the environment is directly associated with how that container communicates with other containers and entities.
In addition to the security risks and challenges, containers pose compliance challenges as well. Cloud-native environments, such the containerized ones, introduce further challenges complying with security best practices and regulatory requirements. Proving compliance at all time with ephemeral and dynamic containers requires automated and continuous monitoring.
Best practices for securing containers
Following the best practices described below can facilitate you overcome these risks and challenges.
- Network policies to control traffic
Network segmentation policies adhering to the least privilege principle might be challenging but it is highly recommended. These policies are a key security control to prevent lateral movement across containers in case an attacker compromises a container. The goal of such policies should be to allow containers to communicate to only those containers that are absolutely required to minimize the attack surface.
Setting up policies is not enough. Monitoring the network activity for anomalies that could indicate an intrusion is equally important. Having an incident and intrusion detection mechanism providing early warning alerts should not be neglected as it can help you minimize the response time and take the appropriate measures to mitigate the compromise.
- Configure resource quotas
In the unfortunate event of a container compromise, having configured resource quotas is very handy. Resource quotas allow you to limit the quantity of memory and CPU resources that a container can consume.
This feature can help you keep your containerized environment efficient and prevent one container or application from consuming all system resources. From a security standpoint, it can prevent an attacker from using a compromised container to disrupt the provision of services or perform other malicious activities.
- Assess the containers’ privileges aka “Don’t Run as Root”
This is common security best practice in all computing environments. Although running applications as a root user may be handy, it isn’t a wise decision. The goal of this security best practice is to adhere to the principle of least privilege and provide the minimum privileges and capabilities that would allow the container to perform its intended function.
Ensure that containers do not run as root by default, by specifying a non-root user to run the container. It always useful to avoid being tempted to let containers run as root simply because it is more convenient. As additional precaution, if you use Kubernetes to orchestrate your containers, you can explicitly prevent containers from starting as root even if an admin attempts to start one that way manually.
- Secure access to registries
Container registries make it easy to set up a central repository from which you can download container images. However, the ease and convenience of container registries can become a security risk if you fail to evaluate the security context of the registry you’re using.
First of all, you should secure the communication these registries by using valid TLS certificates. TLS certificates can minimize the risk of traffic interception and place trust. In addition to securing your communications, you should also restrict the access to these registries using role-based access control to define explicitly who can access what. Balancing user convenience and security is the best way to prevent a breach.
- Use trusted images
Speaking about registries, it is important to highlight the importance of using only trusted images when building your containers. Although this seems obvious, but the truth is that there are third-party registries that do not have any governance policies for the images stored in them. It is important to know which images are available for use, understand their provenance, and review the content in them.
In addition, it is recommended to use images that don’t include unnecessary software packages which could lead to a larger attack surface. Having fewer components in your container reduces the number of available attack vectors. Further, minimal images also result in having increased performance because you end up with smaller size images and less network traffic for images being copied. Finally, implementing a strong governance policy that enforces frequent image scanning can improve your visibility and trust in your images. Images that haven’t been scanned recently should be rejected or rescanned before moving to build stage.
Conclusion
Maintaining container security is very complicated and needs to be approached in a holistic way to harden the environment at multiple levels. Doing so is the only way to ensure that you can reap all the benefits of containers without leaving yourself vulnerable.
About the Author
Anastasios Arampatzis is a retired Hellenic Air Force officer with over 20 years’ worth of experience in managing IT projects and evaluating cybersecurity. During his service in the Armed Forces, he was assigned to various key positions in national, NATO and EU headquarters and has been honoured by numerous high-ranking officers for his expertise and professionalism. He was nominated as a certified NATO evaluator for information security. Anastasios’ interests include among others cybersecurity policy and governance, ICS and IoT security, encryption, and certificates management. He is also exploring the human side of cybersecurity – the psychology of security, public education, organizational training programs, and the effect of biases (cultural, heuristic and cognitive) in applying cybersecurity policies and integrating technology into learning. He is intrigued by new challenges, open-minded and flexible. Currently, he works as a cybersecurity content writer for Bora and is a member of the non-profit organization Homo Digitalis.
Photo by chuttersnap on Unsplash
Author
