Container security best practices: Your guide to securing containers

Over the last few years, there has been a huge adoption of containers. Actually, container technologies have existed for a while, but in 2013, the launch of Docker gave popularity to containers. Docker shows organisations how they can go for container-first development and operations mode. But along with the increase in the use of containers or growth of containers, the risks associated with them also increased. Here in this article, we will discuss container security along with the best practices that can be used for application securing.

In our world, in the world of security assessments and assurance, cloud penetration testing has evolved into much more advanced and focused areas such as Azure Kubernetes reviews, container vulnerability scanning, cluster security reviews and environment-specific white box assessments.

What is container security for DevOps?

Container security is the process of putting security tools and procedures into place to offer robust information security for any workload or system based on containers, including the container image, the operating container, and all the actions necessary to produce the image and get it running.

From a security perspective, there are different layers in container infrastructure, which security implies. Following are some of the main layers of the container:

• Software present inside and the container image
• Communication between the host operating system, container and other containers present on the host system.
• Host operating system
• In the case of the Kubernetes cluster, the container runtime

Each layer here is guided on its own. The first aspect of their guide is the image and the code. A single container can have enough vulnerabilities to reveal your organisation to different security incidents like a data breach or can lower productivity.

Container security across various platforms

Now we will discuss container security across various platforms like Docker, Kubernetes, GKE, AKS and EKS. Let us discuss them one by one.

Docker container security

The change in the building of applications can be observed by the fact that Docker has tens of millions of users, and the number of images pulled is billions. Container security is becoming the responsibility of application developers. Before submitting Docker images to Docker Hub or other registries, it’s critical to examine them for vulnerabilities in Linux kernel packages, user permissions, network settings, open-source software, or access control. Container scanning can let us identify known vulnerabilities and also helps in the remediation of detected vulnerabilities.

Kubernetes container security

Kubernetes provide native security controls to keep your cluster safe and secure applications on running containers. There is one concept that needs to be in mind Kubernetes do not provide auto-configurations. The user needs to configure all the security controls before the container deployment. In the case of Kubernetes, the secure deployment of a container requires expertise because a single misconfiguration can lead to serious security risks.

GKE container security

Here GKE stands for Google Kubernetes Engine. GKE can be operated in two modes. Those modes are standard mode and auto-pilot mode. In standard mode, the underlying infrastructure is managed by the user, whereas in auto-pilot mode, the infrastructure is managed and provisioned by the GKE itself.

AKS container security

Here AKS stands for Azure Kubernetes Service. Azure policy integration and consistent fast updates and patches are some of the robust security features provided by the AKS. However, upgrading cluster components to newer versions necessitates a semi-manual procedure and necessitates enabling network policies while forming the cluster.

EKS container security

A set of strong security features are held by Amazon EKS( Amazon Elastic Kubernetes Service) by default. It runs on AWS shared responsibility model, which explains the responsibility of the individual regarding various elements of container security. Generally, the security “of” the cloud is the responsibility of AWS, whereas the responsibility of security “in” the cloud is carried by the customer. With Snyk, scanning of your Kubernetes configurations and containers can be done, and it also enables automated monitoring as it easily integrates with Amazon EKS and Amazon Elastic Container Registry (Amazon ECR). You can read more about cloud security risks here.

Container security best practices

In this section, we will discuss how we can enhance the security posture of our container environments. Following are some of the useful security best practices for container security:

Restrict container privileges at container runtime

The level at which exploitation of the vulnerability can harm the container environment highly depends upon the isolation level between the other resources and the host and the privileges of the container.

We can use some of the configurations that can be made at the container runtimes to enhance the runtime security of the container. Here are those container runtime settings:

• Effective User – It is recommended never to run the container as a root user unless it is necessary. Even better, utilise randomly generated UIDs (like Openshift) that don’t correspond to actual host users. In Docker and Kubernetes, one can also use the namespace feature whenever ready, but at the time of publishing, it is not available.
• Restrict container privilege – For users, in order to reduce the capabilities and prevent privileged containers, Docker and Kubernetes provide different methods. To limit the activities that the container can perform, one can use AppArmor and Seccomp.
• Add resource limits – Resources like memory, CPU or other mandatory hardware or software resources must be limited so that we can avoid starving for other applications.
• Define Security Context Constraints(SCCs for OpenShift) and Pod Security Policies(PSPs) – Create barriers in your cluster to stop improperly designed containers. If the security context of the PSPs and SCCs does not comply with the defined policies, then it rejects the pods. PSPs and SCCs are admission controllers.
• Shared storage and volumes must be configured carefully – Host path and sharing the filesystem from the host are two of the concepts that must be taken care of.

Following these ways, we can improve the runtime security of our container.

Begin with a minimal base image from a trusted source code

In the case of fast downloads and portability, size matters heavily. The number of parts that can move gets reduced because of this, and this leads to sheltering security vulnerabilities. As we all know, containers consist of the application code and all the libraries, packages, dependencies and other resources required to run the application, irrespective of the underlying infrastructure like the operating system.

In the real world, you may need to operate a large number of applications on different running containers. Then, in that case, you must be aware of the similarities so that it will be easy for you to handle the containers properly.

If you are selecting minimal base images, there are various vendors available online, but one of the most trustworthy vendors is Docker Hub. There are more than 7 million repositories and 3.8 million images, and the number of images pulled per month is even more than 10 billion. Docker also publishes its official images. These images published by Docker are open source and curated by the docker security teams. Images managed by verified publishers are also available on Docker. You can define your own container image best practices by starting with Docker’s standards for these Verified Publishers.

It is very easy to find and pull any image from the Docker Hub. But, while pulling the image, always ensure that the image is from a trusted and verified partner. You can also use a program or tool like Notary to verify the source code and contents of the container images. This way, you can ensure that you are using secure container images.

Securing container images

Containers are built using Container images. In container images, vulnerabilities can be brought into production-deployed containers by malicious or misconfigured activity. Securing container images is required in order to certify your containerised application and workload’s health. This can be done in a few ways:

Include a container image with your application- Together with the application that is created to run in the container, the operation system subset is carried by a container image. Possible threats are constituted by every tool and library that one pull into the image. One needs to include application inside the container image to reduce these threats. All dependencies should be involved in a statically compiled binary.

As little as feasible should be used- All elements that the application is not in need of should be taken out. For instance, the default existing “sed” and “awk” need to be separated from the UNIX system. The Attack surface is reduced by it.

Utilise reliable imagery- One should select trustworthy images if not designing the image from scratch. Anyone can use public image repositories like Docker Hub, and malware or misconfiguration could behold.

Monitoring container activity

Workloads in containers are very dynamic. Often multiple running instances are carried by each container image. Furthermore, At a very high speed, new images and new versions are deployed. Therefore issues can rapidly grow to multiple containers and applications. This is the reason for being highly crucial to recognise these issues as well as remediate each issue at the source.

A granular level of monitoring is needed by containers in workloads in order to give IT security terms and visibility to running components within the environment.

Monitoring tools authorise seamless operations and container security. They help to recognise uneven behaviours and also answer events punctually and in the proper manner. For instance, identifying a faulty image in a timely manner can certify that all suitable containers are rebuilt using the new image after it is fixed.

Security practices should be implemented to control security as well as tools which support achieving observability for the following components:

• Container motors
• Networking and middleware in containers
• Containers running workloads
• Master nodes(while using a container orchestration platform such as Kubernetes.)

Common security misconfiguration and remediations

It becomes very easy for security risks to enter the containerised environment if the clusters, hosts or container runtimes are wrongly configured, or we can say misconfigured. Privileges can also be escalated, and further damages can also be done in the presence of any security misconfiguration. Such security misconfigurations can be identified using the information provided by the CIS(Center For Internet Security) benchmarks, hardening guides and best practices.

They give a clear understanding of the problem and what the problem is, why the problem is happening and how to remediate the problem. The Centre For Internet Security is considered to be the supreme among all the various sources of information. This organisation is basically a non-profitable organisation which publishes security benchmarks. One can find benchmarks for different environments on their site. If any person wants to contribute their knowledge, then they can also do so.

To ensure that you have all those configurations, as mentioned in the benchmark for container security, you can use automation as much as possible. On the basis of static configuration analysis, there are various security tools which exist. These tools enable you to check configuration parameters at various levels. If any security issues are encountered, then they also tell you how you can remediate them.

Securing container infrastructure

We should not only focus on securing the container images or the running containers but also on the management of resources required to run the containers. Using Kubernetes for production orchestration begins with a container registry like Docker Hub. This is because docker containers’ registries provide a place to store and share containers safely. This is done because of the support of container registries to nourish the collaboration to create such a secure place.

They have the capacity to introduce flaws, malware, and revealed information. Some security features and a security protocol called TLS come in-built with the container registries. TLS(Transport Layer Security) is used when a container registry connects with other containers’ registries. Like this, tools for enforcing security controls and creating those controls are integrated into both cluster and network levels in Kubernetes.

A secure system or a secure cloud environment must be used for running containers. In order to access the registry in case of service, we should use Role-based access control(RBAC). One more concept that must be known to you is don’t disregard securing those early development stages because attackers are concentrating their efforts earlier in the CI/CD pipeline. Before using any code in an application or deployment, that code must be scanned using vulnerability scanners in order to build a container or an application.

Manage all the layers in between the base image and your code

Special considerations needed by base image: On top of it, while creating your own image, whatever brings in the base image, you inherit it. There is a possibility that you will require to add tools and libraries in spite of beginning with a slim image. In addition to things to work, there is also a need for necessary installation with your code. All these are necessarily monitored for vulnerabilities.

The good thing is that these middle layers can be directly controlled. It is necessary to give priority to where to concentrate while developing, deploying and testing for production. Various tools at every stage could be required, though during the image tends production, unnecessary things should be removed.

It is simple to separate these tools later by removing them from the Dockerfile and rebuilding them or using multi-stage builds to capture them in a single, automated process. The advantage of beginning with the smallest base is that you only need to add the necessary tools. At the middle layer installed tooling and support packages, few vulnerabilities could be found Though they could be safely avoided if production images were free from all those extras.

Using container security solutions or security tools

Native security capabilities are provided by the container orchestration platform Kubernetes. Even with the native container security capabilities, securing containers or the containerised environment or ensuring container health is impossible. The most challenging part here is that no third-party software components containing any security issues should be included in the containerised workloads.

Rogue processes that are capable of bypassing isolation and gaining unauthorised access to other containers and container images can put containers at risk. If any security vulnerability is present in the image, it will be deployed with the application, which may lead to serious issues. If misconfiguration is present on the containerised workloads, it will increase the chances of new vulnerabilities entering the container.

One can use container security tools to avoid or mitigate the security issues present in the container. Implementing security tools helps you to manage access, protect the container, and test the container’s security. Additional tools can also be used to monitor your cloud-native applications more accurately.

Secure your code and its dependencies

To deliver cloud-native applications rapidly, containerisation is one of the mediums, which is the reason behind the creation of containers. The containers have elaborated the meaning of application code, but developers are still the most direct controller of the code area. To automate the analysing and dependencies code process, it is important to applicable SCA(software composition analysis) and SAST( static application security testing) together with integrated scanning, as the amount of proprietary code can easily be dwarfed by open source dependencies. Scanning containers to directly find issues in Git commits and repositories is possible, which is better for the development process.

Use access management

If we talk about containers, then in their case, access means permission to perform a specific operation over a specific container. Create, read, update, or delete (CRUD) operations broadly refer to common actions or operations that are basically performed over the containers. How access is defined is totally dependent on the container platform. In the case of Kubernetes, the users are trying to access the containers from the external world; therefore, it is mandatory for administrators to properly authenticate them using OAuth2, TLS certificates and other means of authentication.

The principle of least privilege should be implemented for network access and traffic. The administrators must handle only the creation of infrastructure. You should designate each container with a defined set of roles and responsibilities, then utilise tools to make these roles easier to carry out, enforce, and monitor in order to prevent a container from having full access to all of your resources.

Securing registries

Private or public registries generally store container images. Securing these registries to check that all collaborators and all team members use vulnerability-less images is critical. To secure container registries, a few ways are mentioned:

• Scan your images – Known vulnerabilities are identified by a vulnerability scanner. Also, finding critical vulnerabilities and discovering critical threats are done by it. To certify that the registry is free of critical vulnerabilities, scanners can be used continually.
• Sign your images – signatures allow you to track who signed them. For a compromised image, the substitution of a signed image is difficult. The Docker content Trust mechanism gives information about signing images. An open-source tool, Notary, can also be used for signing and verifying images.
• Use access control – Who can access and publish images and who cannot do these functions are determined by the access control, which needs to be established in case of a private registry. Modification, deleting images, and publishing by unauthorised parties can be prevented by Access control, which is a basic security measure.

Conclusion

Securing your containerized applications can be a daunting task. It’s not something you can do overnight, but it’s important to take a proactive and layered approach to security.

Containers are becoming more and more popular, but unfortunately, they’re also becoming a bigger target for cybercriminals. They’re looking for new ways to exploit your assets, so it’s important to take the necessary precautions.

Cyphere offers cloud security reviews, including in-depth assessments around docker, Kubernetes, azure, aws, gcp. We’ll work with you to develop a strategy that fits your needs and helps keep your assets safe from cyber criminals.