Mirantis Container Image Registry Now Supports Any K8s Distro
Mirantis this week updated its private container image registry to enable it to be deployed on any distribution of Kubernetes.
Previously, the Mirantis Secure Registry was only available for Mirantis Kubernetes Engine, a distribution the company curates on behalf of its customers. Version 3.0 of Mirantis Secure Registry was formerly known as Docker Trusted Registry before Mirantis acquired the enterprise assets of Docker, Inc.
Adam Parco, Mirantis CTO, says since then Mirantis has been working to modernize a container image registry that makes it possible to scan for vulnerabilities in container images and prevent their use if a critical vulnerability is discovered.
Rather than depending on a public container image registry, more enterprise IT organizations are deploying their own private container image registry to better secure their software supply chains. This shift is occurring in the wake of a series of high-profile security breaches that resulted in cybercriminals inserting malware within multiple applications.
In theory, microservices-based applications should be more secure than the previous generations of monolithic applications. Those monoliths are difficult to patch every time a new vulnerability is discovered. It’s much easier to rip and replace a container that encapsulates a specific piece of vulnerable code. The concern is that container images downloaded from a public registry may already be compromised—whether inadvertently or deliberately—because the code being used has known vulnerabilities. Developers, for example, might accidentally employ an older version of a component with known vulnerabilities that cybercriminals can easily exploit.
A private registry improves the security posture of an organization by giving it more control over which container images are used and who within the organization is allowed to create and share those container images.
There is, of course, a major effort underway to shift more responsibility for application security toward developers via the adoption of DevSecOps best practices. The degree to which those efforts will succeed will vary widely based on both the aptitude of the developers and the quality of the tools they are provided. Most developers, however, are still always going to be more focused on writing code than they are on security. It’s largely up to IT teams to put the mechanisms in place that ensure all the code being promoted into a production environment is truly secure.
In fact, the goal may not be to shift responsibility for application security completely left as much as it is to enable the IT operations teams to lean further left to reduce the number of opportunities for developers to make a mistake.
Regardless of the approach, it’s apparent that cybercriminals are increasingly targeting containers. It’s already relatively easy for cybercriminals to insert malicious containers within an IT environment to illicitly mine cryptocurrency. As more mission-critical applications are built using containers, it’s only a matter of time before threats aimed specifically at container images become both more prevalent and more lethal. In fact, any effort to secure a modern software supply chain based on containers needs to arguably start with the registry that is employed to house them.
