Developers around the world adore software containers thanks to their portability, scalability, and efficiency. They are the backbone of today’s microservices-driven architecture. According to a recent survey by Dell, more than 50% of enterprise applications are in containerized environments.
Because containers are built on open source, container registries like Docker Hub offer free downloads of hundreds of thousands of software packages. But is it wise to download a free container image and run it in production? Probably not.
Just because a container image is popular or distributed by a trusted source doesn’t mean it’s safe or secure to run in your infrastructure. In fact, it’s highly likely that any container you download online comes riddled with security vulnerabilities and risks. This is why you need container hardening.
Container hardening is a two-step process:
Software Component Analysis (SCA) scanners detect security issues such as Common Vulnerabilities and Exposures (CVEs). Scanners are important security tools and check against vulnerability databases like cve.mitre.org.
A container can never be perfectly safe. Even small containers can have vulnerabilities, and even hardened containers can have undiscovered vulnerabilities. Open source builds upon open source, using dozens (if not hundreds or thousands) of software dependencies. Software is written by humans - and humans write buggy software.
Hardening a container minimizes its attack surface, which makes it more secure. It does not eliminate the attack surface. Hardened containers are still likely to have vulnerabilities, but the risk of a breach due to known vulnerabilities is as low as possible.
Nobody wants their production infrastructure breached by malicious cyber attacks. The after-effects of a breach are laborious, expensive, and could put a company out of business.
Hardening containers does more than protect infrastructure from attacks and breaches:
Container image hardening is an important practice that every organization should take to protect their applications and data from attack; meet compliance requirements; reduce their attack surface; and develop a culture of security and trust.
Containers are portable software packages that run on a Linux-based host operating system as separate processes, like an application. Virtual Machines (VMs) are entire computing environments in a single file. VMs emulate a computer system that can run its own operating system and applications as if it were a physical computer. A VM file contains its own hard drive storage and uses a share of a host computer to execute its internal processes.
In principle, container hardening and VM hardening are practically the same thing: run a vulnerability scan, then remediate detected vulnerabilities. However, the actual work of scanning and remediating is quite different. VMs contain an entire operating system, such as Microsoft Windows Server 2022, and all of the applications that may or may not be needed to run on that virtual machine. It works and appears as a completely separate computing device on a network.
This fundamental difference between the two technologies means that VMs have a much larger attack surface than a container. Containers only include the necessary components to run the applications they contain. VMs include much more. Hardening a container is much less complex than securing a VM image.
VMs, however, are much more isolated than a container. They are self-contained, whereas a container shared resources with its host. If an attacker gains access to a VM, they are likely to have less access to the host system and the surrounding environment than a container breach.
Because containers are more scalable across the development lifecycle and better suited for dynamic provisioning, they may require more careful management to ensure security across a large number of instances.
Container image hardening does have best practices, but there’s not really a set of standards to determine whether a container is properly or sufficiently hardened. Infrastructure and application security can be a sort of cat-and-mouse game because new vulnerabilities are discovered in existing software on a regular basis, just as we saw with Log4j in 2021.
Every organization has its own requirements and acceptable risk levels for security. Some organizations may even have varying requirements across departments or lines of business. However, the widespread proliferation and adoption of open source software has gotten attention from the federal government. For example, the U.S. Department of Defense (DoD) has its own container hardening process guide which can be a helpful indicator and the White House has issued an executive order to improve federal cybersecurity.
Some of the emerging best practices for Docker container hardening include:
A comprehensive set of container security best practices is illustrated in the figure above. Every step can be deployed via automation in a standard CI/CD pipeline.
The hardening process should:
A hardened Docker container should have the smallest possible attack surface based on the risk tolerance for running that container in production. This should be measured against organizational security and operations standards (e.g. “No critical vulnerabilities allowed in production”), fully documented and auditable, and - wherever possible - fully automated.
RapidFort is the world’s first Software Attack Surface Management platform, built and designed from the ground up by software developers and security professionals. You can harden containers for free on our software attack surface management platform.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。