Three Advantages of Mirantis Secure Registry
Mirantis Secure Registry, just released in version 3.0.4, provides vulnerability scanning using Synopsys’ peerless CVE database
Mirantis Secure Registry (MSR), just released in version 3.0.4, provides high-performance, secure container registry services – storing versioned images of built containers for deployment on Kubernetes, Swarm, or stand-alone container hosts.
Normally deployed as a containerized workload on Kubernetes, MSR provides container registry services for some of the world’s biggest cloud native programming teams and most demanding projects. Properly configured, a single instance of MSR can serve literally thousands of developers.
Automated vulnerability and malware scanning has long been a feature of Mirantis Secure Registry. Vulnerabilities – as well as actual malware – can find their way into containers easily, as part of base images (perhaps retrieved from a public registry), images provided by third-party vendors, or as code delivered along with installed software packages (think NPM packages) and built into containers as software projects come together. CVEs in production containers expose you to exploits. Active or passive malware within containers can be even more diabolical. So this is a real and ongoing problem for anyone developing cloud native applications.
Recent generations of MSR satisfies all FedRAMP (US Federal Government general standards for cloud services) requirements. It accesses Mirantis’ centralized database of CVEs and malware, continually updated from the enormous database maintained by Synopsys.
Below are three important reasons why Mirantis Secure Registry is the best container registry choice for any cloud native software development and orchestration scenario. These reasons are also why Mirantis packages MSR as the default registry in Mirantis Kubernetes Engine Kubernetes/Swarm clusters and in Mirantis Container Cloud – our multi-platform cloud building, operations, and lifecycle management solution.
1. Protecting users and data - scanning, secure software supply chain, signing, and execution prevention
MSR plays a crucial role in what Mirantis calls “the secure software supply chain” – a highly-automated containerized-software delivery workflow. In a secure supply chain, container workloads produced by developers are scanned when built (i.e., for Common Vulnerabilities and Exceptions – CVEs). Thereafter, scan reports, test data, and other information (workflow- and requirements-dependent) must be checked by human operators before these authorized persons cryptographically sign the binaries.
Signing makes those workloads executable on specific container hosts (for example, hosts in a production cluster). Unsigned or improperly-signed workloads are rejected and flagged. The feature is called execution prevention, and is provided by Mirantis Container Runtime.
Secure supply chain can be used many different ways (see below). Its big job, however, is preventing unchecked and unsigned workloads from executing in sensitive environments (such as on production clusters) – a powerful, simple tool for enforcing rigorous security and preventing malware from executing in critical environments, potentially putting user data at risk.
2. Making devs more productive while reducing security risks
Automated scanning of built containers provides security against CVEs and malware making their way into production workloads. But containers are complex, and finding a CVE late in container development can mean tearing down the container’s configuration (perhaps all the way down into the base image) and replacing key components – creating a time and expertise crunch. But how can you prevent it?
Many MSR users have adopted the best-practice of using scanning in an effort to create and maintain a library of clean, standard base images, documenting these and making them available to front-line developers. This doesn’t completely eliminate the problem – new CVEs can, for example, be discovered in software previously thought to be vulnerability-free. But it makes problems with base images much less likely to occur, freeing developers to innovate.
Secure supply chain and image signing, meanwhile, can be used to efficiently enforce workflows for orderly development, testing, QA, and to strongly segregate dev, test, QA, and production environments. Doing this correctly can basically eliminate the possibility of human error causing (for example) a container under development to make it onto a production cluster. Constrained, efficient, automated workflows tend to move much faster – developers feel confident and learn the routines quickly.
3. Ensuring regulatory compliance
Secure supply chain and cryptographic signing provides an unambiguous, fakery-resistant audit trail of cryptographic signatures for forensics and governance – easily accessed by authorized administrators (it’s right in the MSR webui). You can see exactly who promoted a workload to production, and when it happened. This level of detailed information is essential for all kinds of forensics and required for good IT and data governance.
Automated Scanning Pays Off
Scanning container images pays off in many individual ways and contexts. Collectively, these sum to mean acceleration: development teams can move more quickly, with greater assurance and more-predictable outcomes, once scanning is in place and workflows and policies adjusted to make it an inescapable dragnet for flawed and evil code. To try MSR, check out the docs.