Understanding Container Security

Containerized architectures are one of the most popular technologies for developers. There are many advantages to migrating to the containers, I think the most important advantage is flexibility. You can build your Docker images and containers only once, and deploy wherever you want. In addition to this advantage, there are also lots of security challenges. Many attack surfaces surround your container environment if your container structure has lots of security misconfiguration and vulnerabilities. While being very flexible, you may encounter attackers and lots of exploit scenarios in your containers.

Container security has lots of aspects. As security professionals, these are our responsibilities in a container environment:

• Secure your codebase
• Secure your app
• Secure all libraries that you’ve used
• Secure your network/communication
• Secure your CI/CD processes

In this blog, we will talk about container security challenges and what should you do about them. Let’s start together! ✍️

Container Security Challenges

1) Vulnerability Overload 🥴: There are lots of vulnerabilities in different layers in a container image or containers in runtime. Developers are confused about the prioritization of these vulnerabilities, how to fix them without any functional errors, and who is responsible for remediating them. Prioritization is important because if you have 100 critical vulnerabilities in a container cluster, you need to know which are the most critical ones. At this point, analyzing the vulnerability scan results is an important task for you.

2) Container security is challenging 😮: There are a lot of layers and aspects in a container such as networking, codebase, and libraries that are used, etc. We need to know all details about all of these topics and you need to get action about them. Also, if there is a vulnerability in a container system, you need lots of information about some questions like: “What is the exact vulnerability scenario in there?”, and “How is this vulnerability affect our system?”.

3) Difficulty in Integration 🧗🏻‍♀️: There are lots of scanning, vulnerability management, and alerting tools about container security. In your company, you need to decide what is the best tool for managing your container environment. In addition to this, you need to think about our CI/CD pipeline and at which point you need to integrate these tools in order to be protected.

✨ Security Points of Containerized Design ✨
As we mentioned before, you should think of every potential attack vector at each stage of a container’s lifecycle.

1) 🤔Vulnerable Application Code: Lots of code parts are added to a container environment in your daily work. You’re using lots of libraries, third-party codes, and our business logic codes. You need to be careful about secure code best practices when you’re writing your application code.

• You need to follow OWASP guides about secure code design.
• You need to scan your code with SAST tools like SonarQube, Veracode, etc. These tools help to understand the security of your code.
• Scanning your container images for vulnerabilities is a good approach. But this scanning is not one time job, it should be done regularly (weekly, monthly, etc.) You need to follow vulnerability reports and fix all of the vulnerabilities as soon as possible. I recommend some open-source tools that could be useful: Trivy, Docker-Bench, Grype.

2) 🤔 Badly Configured Container Images & Containers: If an attacker is able to modify the Dockerfile, it’s possible for them to take malicious actions such as adding malware or crypto-mining software into the image, accessing build secrets and privilege escalation, etc. These are very dangerous activities for container systems. To prevent this, we need to write our Dockerfiles with security best practices. Here are some best practices that I’ve recommended:

• You should use an image from a trusted registry. Please do not use any base images that are not verified, or built by someone that you do not know. Attackers love this way to catch you.

• You should use smaller base images for your infrastructure. When you use the smaller one, you have less unnecessary code and a smaller attack surface.

• Please do not be root and run any code with root in your Dockerfile. You should always define a user with at least a privilege approach. Root users are always critical to us.

• Remote code execution scenarios are critical for containers. You should check your RUN command to prevent running the codes that you don’t have or attackers can. You should audit your RUN command logs regularly. Also, access control is critical at this point. You need to clarify and define which users in your system have the change RUN command.

• For your Dockerfiles, you can also scan them. There are lots of tools that can check your Dockerfiles. They will validate if Dockerfile is compliant with Docker best practices such as not using root user, making sure a health check exists, and not exposing the SSH port. You can use Snyk and Checkov.

3) 🤔Exposed Secrets: Exposed secrets are a nightmare for us. As in every environment, we’ve mentioned “Please do not hardcode your credentials.” You should not store sensitive data in different layers in your containers. You think if you’re using the remove command everything is fine, but believe me, it’s not. Your credentials are still in layers and docker history and attackers can get these credentials by reversing your container image. To prevent exposure, you should rotate & encrypt your secrets regularly, not store them in .env files and you can use secret management tools like Vault.

4) 🤔Image Storage Security: We’re using AWS ECR, DockerHub as image storage. While you’re using and pushing your images, you need to be sure these are not publicly accessible. Attackers love founding publicly accessible Docker images, reversing them, and getting all your system details, credentials, etc. Also, to ensure your docker data integrity and docker content trust, your Docker images should be signed and verified on runtime. We don’t want to use images that attackers changed and pushed our docker storage area.

Access control is a critical topic there. You need to decide which users in your company should access which Docker images with which access roles. You should check your image tags and YAML files before running them in your production cluster. You should be aware of everything about your Docker images.

5) 🤔Insecure Networking: Every external attack reaches your container deployment across a network area. So you need to implement a strong secure network infrastructure for your containers. You need to implement a VPC, default deny mechanism on NACLs, security groups, and firewalls. You should restrict your container ports wherever possible. For network traffic, you always think of using Web Application Firewall (WAF) solutions. WAF helps to prevent lots of attacks such as RCE, SQL injection in addition to network layer attacks. And as you know, you need to always use TLS for your encrypted traffic. Attackers love HTTP, not HTTPS.

Thanks for reading! Stay safe in containers! 👻