Guest post originally published on SparkFabrik’s blog
Containerized applications are becoming increasingly more common, and with their deployment comes an increased need to ensure adequate container security and resilience of the software supply chain. In this article, we will outline the main container-related security issues, together with the best practices to adopt to enhance them.
Container security: the context
The way organizations design and develop software has changed dramatically in recent years. The advent of Native Cloud architectures based on microservices and containers has been a true game changer in the IT landscape. Today, applications are no longer created based on a monolithic approach. Rather, they are designed based on microservices architectures, according to DevOps methodologies that do not leave the operational management and the security-related aspects to the Operations teams downstream in the development cycle.
According to Gartner, the container management platform business will reach $944 million by 2024, up from an estimated $466 million in 2020. This double-digit growth highlights just how container technology is gradually becoming increasingly more widespread within organizations of all sizes (here are three examples of companies using containers successfully).
And with containerized environments becoming more and more prevalent, finding solutions to improve container security has moved to the top of the priority list for security teams and devsecops.
YOU MIGHT ALSO BE INTERESTED IN
The DevSecOps: Cybersecurity for Cloud Native Applications article
What are the main security issues related to containers?
When discussing container security, we must reason within a spectrum ranging from the simple containerized workload, to the host that facilitates the execution of that application or microservice. With this idea in mind, we can clearly identify the key security problems that every organization must pay attention to. Let’s take a look at them one by one.
KERNEL EXPLOIT
Sharing the kernel of the host machine exposes all containers running on it in the event of an attack that takes advantage of an operating system exploit. This risk is strongly mitigated by classical hypervisor-based virtualization. In fact, this practice adds an additional layer before the running applications are reached. Patching and hardening of the host operating system is thus of paramount importance in container environments.
DENIAL OF SERVICE (DOS) ATTACKS
Let’s assume that a container has the ability to access unlimited resources in terms of computational capacity on the host system. Exploiting an application vulnerability or a programming error could therefore greatly monopolize available computational resources, preventing other containers from accessing CPU and RAM and causing a DoS attack.
Fortunately, this scenario can be prevented by appropriately configuring the resource allocation dedicated to each container and the key parameters to allow efficient horizontal and vertical scalability.
CONTAINER BREAKOUT
In case of a bug present within an application, a user could climb the privileges pyramid up to the root level and gain access to the host. Despite the remote possibility of this event actually happening, periodic checks should be planned to validate the robustness and security of containers in production.
INFECTED IMAGES
Standard container images (builds) can be infected with malware or have known vulnerabilities. It is therefore critical to always keep container images updated to the latest available version. In addition, it is good practice to conduct periodic checks on their security running appropriate scans.
COMPROMISED SECRETS
During the execution of applications, the container periodically accesses sensitive information, API keys and credentials. Unwanted access to this information would compromise the entire security of the running services.
In some cases, the consequences can be quite serious, which is why it is a good idea for organizations to familiarize themselves with security best practices, such as those we will look at in a moment. First, however, there is another concept that is good to address, that of supply chain software.
Supply Chain Security Management
The growing popularity of Cloud Native architectures has indirectly resulted in a positive growth in the adoption by organizations of software solutions of all sizes defined as “open”. Open source software (OSS) leaves the management, maintenance and evolution of the software in the hands of the community, with a strong preference for collaboration and insights for improvement based on user feedback.
The use of OSS software by private companies is regulated and protected by traditional licenses (e.g. MIT, GNU GPL, etc.). However, the management of risks and threats arising from the use of open software is left to the organization.
In this context, the concept of Supply Chain Security Management is critical, since in an “ungoverned” environment it is not possible to control and manage the use of third-party SDKs, libraries, or tools. It thus becomes necessary for a process that guarantees the immutability of a dependency or of the software itself to be put in place, protecting the perimeter of our infrastructure from a malicious third party.
The traditional method for verifying software integrity has been to verify the digital signature of the application components. The same concept is also applicable to containers but, unfortunately, this is not enough.
According to the Supply Chain Level for Software Artifacts (SLSA) standard, in order to achieve an appropriate level of software supply chain security, a structured approach must be adopted. The four areas that characterize this approach are: Artifacts, Metadata and Attestation and Policies. Exactly what are we talking about? We have described these concepts for you below.
- Artifacts: the starting point of the analysis, in other words the output produced by the Build process, which can be in different formats and of different types.
- Metadata: structured and unstructured data describing software artifacts. Certain types of metadata must be looked at and verified to validate the supply chain:
- Provenance Data, in other words information regarding the build system that produced that artifact (machine identity, compiler version, CI/CD tool, etc.). There is currently no standard for documenting this information. However, CNCF’s in-toto tool provides a number of technological solutions to document and verify this information.
- Software Bill of Material (SBOM), in other words the list of ingredients (such as frameworks, libraries, etc.) used by the application.
- Vulnerability Scan Report of the containerized code generated through static code analysis systems.
- Attestations: the metadata produced, but digitally signed by a trusted identity. Tools such as sigstore Cosign are able to integrate with in-toto to associate attestations with containers.
- Policies: attestation verification mechanisms to arrive at the final supply chain verification. For example Kubernetes offers the capability of admission control, which makes it possible to verify a component before it is installed within the cluster. Tools such as Kyverno leverage this Kubernetes feature to provide a flexible and configurable policy engine.
6 best practices for container security
Now that we have described the main challenges in terms of Container Security, we can finally look at security best practices. These are the recommendations that, added to a robust software supply chain verification process, make it possible to keep our containerized workloads under control and reduce the attack surface. We have identified 6 key best practices.
1. IMAGE SECURITY
A vulnerable or compromised base image can lead to problems for all workloads that use it as a base. It is therefore always a good idea to customize the base image of the container as little as possible (e.g. by adding external packages or SDK libraries). It is also good to use only images from certified and reliable sources.
2. IMAGE REGISTRY SECURITY
Registries are the repositories of the containerized software images. To keep this type of repository secure (both from unwanted access and vulnerable content), different strategies can be adopted:
- Using access control policies to limit access/actions.
- Using container image signing.
- Finally, making use of continuous image scanning using plugins built-in the registry service to detect known vulnerabilities within the base images used.
3. SECURING THE DEPLOYMENT
Considering a production environment as the target of our deployment process, this phase can be secured in several ways:
- Physically protecting the environment with dedicated firewalls or network security rules/groups.
- Using an orchestration platform that typically provides secure API endpoints and that supports role-based security.
- With “immutable” deployments, in other words reinitialized when changes occur.
4. SECURING THE APPLICATION RUNTIME
It is a good idea to follow traditional best practices in the context of Cloud Native architectures, such as:
- Creating separate virtual networks for workloads that are different in nature and disconnected from each other.
- Applying the least privilege principle on the communication channels/ports that each container can use, thus only exposing strictly necessary ports.
- Using secure connections (TLS based) to ensure traffic encryption.
5. USING MINIMAL AND SHORT-LIVED CONTAINERS
Containers are not meant to be used as “servers”. Their customization and the files contained within them should therefore be minimized, maintaining the ephemeral nature of each instance of a container.
6. MONITORING CONTAINER ACTIVITY
This last objective is achieved by implementing mechanisms that provide a deep level of observability on the following components of the containerized infrastructure:
- Master nodes (for Kubernetes based orchestration);
- Container engines;
- Workloads running in containers;
- Containerized middleware and networking.
In a nutshell
To avoid running into security problems and to ensure container security, every organization must review its application lifecycle management processes. These processes must be reinforced with all the necessary mechanisms for verification, remediation and monitoring.
In order to minimize the potential attack surface, organizations need to be aware of the main container security issues, follow a structured approach to ensure an appropriate level of security for the software supply chain and apply the best practices that we have outlined in this article.
Finally, it is essential to put into practice the famousshift-left principle, anticipating security practices from the early stages of the software development lifecycle. This is a pivotal process in the DevSecOps philosophy, which we recommend that you take a close look at if you haven’t already done so. We also discuss it in the free ebook we have dedicated to Cloud Native Security (in Italian only).