Joshua Jebaraj
May 16, 2023

Keystone Principles for Container Security

Table of Contents:

  1. Introduction
  2. 9 Best practices for securing your containers
  3. Conclusion

Containers have become a popular technology for software development and deployment, especially with the rise of container orchestration platforms like Kubernetes and Docker. 

However, with great power comes great responsibility, and container security is a crucial aspect that cannot be overlooked. 

This article will discuss the keystone principles for container security that every developer and operations team should know when using Docker.

9 Best Practices for Securing Your Containers

Container security has been on the rise because of the increased usage by some, or rather can we say, most big and even smaller IT companies globally. 

If you are new to container security and want expert assistance in fortifying your company's Kubernetes application, you can reach out to the We45 team!

Read ahead to learn the best practices to safeguard your container from threat actors.

A Container is NOT a Full-Fledged OS

The first and foremost principle to remember is that a container is not a full-fledged operating system. While containers provide a lightweight and isolated environment for running applications, they are not meant to replace a whole operating system. 

Therefore, running only one process or service per container is recommended, as it helps maintain isolation and scalability. If multiple services run in a single container, scaling them independently and troubleshooting issues can become difficult.

Avoid Using Linux Distros to Run Services in a Container

Another principle is to avoid using Linux distributions like Ubuntu, Debian, and others to run services in a container. These distributions come with many excess codes and libraries that the container doesn't need, increasing the application's attack surface. 

Instead, it is recommended to use minimal base images like Alpine, which provides only the essential packages needed to run the application.

Use ONLY Trusted Base Images 

Using only trusted base images is a critical aspect of container security. When building a container, the base image serves as the foundation on which the container is built. 

Therefore, using a base image from a trusted source is crucial to avoid potential security breaches. Using an unverified image can lead to the inclusion of malicious code, which can compromise the entire container and the host system. 

Using official images from trusted sources like Docker Hub is the best way to ensure the base image is safe. 

Vendors have created and maintained official images and have undergone rigorous testing and scanning for vulnerabilities. Moreover, official images are regularly updated with security patches to address known security issues. 

By using trusted base images, organizations can significantly reduce the risk of miscellaneous security breaches and ensure the integrity of their container environments.

Don't Store Secrets In Dockerfile

Keeping secrets such as passwords, API keys, and other sensitive information in the Dockerfile is not recommended, as it can compromise the security of the container. It is crucial to ensure that the sensitive information is not exposed to unauthorized individuals who may have access to the image. 

A better approach is using environment variables or secret management tools to store sensitive data, such as HashiCorp Vault or AWS Secrets Manager. 

Secrets management tools provide a secure way to store and manage secrets, ensuring that only authorized individuals can access them. Using these tools, you can easily manage and update the secrets without modifying the Dockerfile.

Don't Run Containers as Root Users or With User ID = 0.

Running containers as the root user or with user ID = 0 can lead to serious security risks, as it grants the container full permissions to the host system. 

Therefore, using a non-root user or creating a new user specifically for the container with the least privilege required to run the application is recommended. 

Using a non-root user provides a more secure environment by reducing the potential damage an attacker can do if they compromise the container. 

The user should be created with the minimum permissions necessary for the application to function. This approach limits the capabilities of the container and reduces the potential for security breaches. 

Avoid Using Docker-Commit To Recreate An Image

When using a Docker container, keeping track of any changes implemented to the image is essential. While it could be tempting to use the docker-commit command to quickly create a new image based on an existing container, this method is not recommended. 

Docker commit is not a good way to keep track of changes to an image, as it does not allow for version control or documentation.

Instead, it is recommended to use a Dockerfile or other source-to-image (S2I) approach. Using a Dockerfile, you can document and version your changes to the image. The Dockerfile contains a series of instructions that describe how to build the image. Each instruction creates a new layer in the image, making it easy to track changes over time.

The Dockerfile can be stored in a source control repository like Git. This allows you to track changes to the file and easily roll back to previous versions if necessary. 

By using a source control repository, you can ensure that your Docker images are consistent and well-documented.

Use Docker Image Tag System for Versioning

When building Docker images, it is crucial to have a consistent way of versioning them. One common approach is to use the Docker image tag system. Docker images can be tagged with a specific version number, such as "v1.0.0". This allows you to easily track which version of the image is currently in use.

Building a new Docker image for every commit to your Git repository is recommended. The Git commit ID can be used as a tag for the Docker image, allowing you to trace which commit a particular image belongs to. This approach can help you quickly identify the source of any issues in your application.

Docker Containers Are Ephemeral

When it comes to container security, data storage is often overlooked. Docker containers are temporary, meaning they can be stopped, destroyed, or replaced at any time. 

Therefore, storing persisting data in a container, even a writable layer, is a bad practice since all the data will be lost if the container is destroyed. To avoid this, volumes should be used for data storage. Volumes are directories outside the container's filesystem, allowing you to persist your data even if the container is destroyed. 

Moreover, volumes enable data sharing between containers or the host system, providing greater flexibility and scalability. Decoupling data from the container using volumes ensures better security, flexibility, and scalability for containerized applications.

Exposed Sockets, Sensitive Volumes, and Ports

Pay close attention to what elements of your containerized applications and infrastructure are exposed to the public. Exposed sockets, sensitive volumes, and ports can be a potential attack vector for malicious actors to exploit and compromise your systems and data. 

You must ensure that only the necessary elements of your containers and network are accessible to the public and that sensitive data is properly secured and encrypted. 

By carefully controlling what elements of your containerized environment are exposed to the public, you can reduce the risk of cyber-attacks and amp up the holistic security posture of your applications and infrastructure.

Conclusion

Containerization has revolutionized how we develop, deploy, and scale our applications. 

However, it has also introduced new security challenges that must be addressed to protect our systems and data from cyber-attacks.

By following the keystone principles for container security discussed in this article, you can significantly reduce the attack surface of your containerized applications and improve their overall security posture. But securing containers and Kubernetes environments requires specialized knowledge, experience, and expertise.

That's where we45 comes in. With our comprehensive Kubernetes security and container security services, we can help you secure your containerized applications and infrastructure from the ground up. 

Our team of expert security consultants, engineers, and developers has a deep understanding of the container ecosystem and can help you implement the best security practices and solutions for your unique needs.

We offer various services, including container security assessments, Kubernetes security assessments, secure DevOps, and cloud security. Our services are designed to help you identify vulnerabilities and risks, implement security controls, and continuously monitor and improve your security posture.

With we45's Kubernetes security and container security services, you can focus on your core business objectives while we take over your security needs. 

Contact us today to learn how we can help you secure your containerized applications and infrastructure.