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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
Considering a production environment as the target of our deployment process, this phase can be secured in several ways:
It is a good idea to follow traditional best practices in the context of Cloud Native architectures, such as:
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.
This last objective is achieved by implementing mechanisms that provide a deep level of observability on the following components of the containerized infrastructure:
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 famous shift-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).