Mirantis Secure Registry 2.9.0 Released

More than "just a private image registry," Mirantis Secure Registry now delivers rich Helm support with chart linting, plus new security features like Running Image Enforcement

Mirantis recently released version 2.9.0 of Mirantis Secure Registry (MSR, formerly Docker Trusted Registry) — delivering a host of new features to make private registry more useful, more informative, and more secure.

If you're not using Secure Registry, getting started is easy. MSR runs on a Mirantis Kubernetes Engine worker node under Swarm orchestration. Our download recipe, for example, uses the Mirantis Launchpad deployer to create a three-node (one controller, two workers) Kubernetes Engine cluster, then uses the Docker CLI on one worker to install Secure Registry. More sophisticated MKE deployments that include Secure Registry are easily created with Mirantis Container Cloud, or with Mirantis Launchpad.

New features in Mirantis Secure Registry 2.9.0 include:

Helm 2/3 Support

Helm is rapidly becoming the de-facto standard for defining modern application deployments, and, as such, has become a cornerstone tool for automation.

We've been hearing from many of you that supporting Helm would make the registry much more useful. And we listened. Mirantis Secure Registry 2.9.0 now provides native support for Helm 2 and 3 charts. By exposing the standard Helm API, MSR becomes fully Helm-compliant — so the Helm CLI and related plugins (such as ChartMuseum’s helm-push) can be used to maintain your collection of Helm charts within Mirantis Secure Registry.

Mirantis Secure Registry 2.9.0 stores Helm 2 and 3 charts, interoperates with the Helm CLI and community tools, and provides a handy user interface, letting you view chart dependencies, default configurations, and auto-generated linting information.

Mirantis Secure Registry 2.9.0 also provides a user interface to view the Helm charts it is storing. You can:

• List the Helm charts hosted by MSR, including available versions of each
• Review chart dependencies
• Display the default configuration associated with a chart
• Show the fully-rendered template for a Helm chart
• Display auto-generated Helm static analysis and linting info, to identify security risks and help ensure adherence to coding standards and best practices (see below)

To ensure the integrity of Helm charts, MSR also includes support for Helm Provenance data, to help ensure that users consume only original and unadulterated Helm configurations in their deployments.

Developers who use Lens, the Kubernetes IDE, will appreciate that Mirantis Secure Registry can be configured in Lens as an external Helm repository, making it simple to apply Helm charts from MSR as part of your normal Lens workflow.

Helm Static Analysis

Helm provides a world of opportunities for innovation — making it easy to acquire, modify, combine, and extend charts from many sources. But this creates opportunity for mistakes (and/or deliberate exploit injections) that can compromise deployment and cluster integrity.

To ensure that your Helm charts follow established best practices, Mirantis Secure Registry 2.9.0 now provides integrated static analysis — automatically surveying your Helm charts and detecting patterns that may put your deployments at risk.

Mirantis Secure Registry 2.9.0 offers static analysis of stored Helm charts, automatically detecting and identifying risky patterns and providing steps to remediate.

Among many other potential vulnerabilities, MSR can detect the following risky patterns being used in your Helm charts:

• Container permits runAsNonRoot
• Container mounts a writable path to the host filesystem
• Container permits NET_RAW access

MSR even provides remediation steps that can be taken to resolve the problem, speeding risk mitigation.

Running Image Enforcement

While adding Helm support within MSR, it became evident to the folks here at Mirantis that the security provided by static analysis for Helm charts was great for Helm itself, but fell short of protecting deployed image content from compromise. That’s why we paired it with a new feature called “Running Image Enforcement.”

Leveraging MSR's industry-leading image scanning and CVE detection capabilities, the registry itself can now be configured to prevent pulling images that match defined criteria, e.g., higher than expected CVE counts.

Running Image Enforcement provides a simple set of web tools for building conditional logic that MSR can then automatically apply to determine whether to prevent pulls of designated container images.

Pull-prevention logic is characterized according to standards of the Common Vulnerability Scoring System (CSSV) version 3.0 specification — a widely-used industry standard set.

Extending best practices used in Secure Registry's built-in image scanning, Running Image Enforcement lets you define granular policy in accordance with the Common Vulnerability Scoring System (CSSV, version 3.0) standard. Enforcement policies let you prevent container deployment based on:

• Total count of CVE vulnerabilities, regardless of severity level
• Count of CVE vulnerabilities at each CVSS3 severity level (“Critical”, “High”, “Medium”, “Low”)

You can combine the above CVE policies with tag and component names as well, enabling extreme conditional flexibility. For example, by combining the use of image tags and CVE counts, policies can permit deployment of development or testing images containing more vulnerabilities, but prevent deployment of these same images to production.

Mirantis Secure Registry Running Image Enforcement can also police container images by license type, making MSR useful in ensuring compliance with commercial software licensing and/or support agreements.

Enforcement policies can be configured with two scopes: Global and per-repository. Each scope serves a different need, depending on the policy goals.

Globally-scoped policies let you enforce organization-wide security standards across all hosted repositories. These policies are always evaluated before repository-specific policies, and cannot be overridden at the repository level. This can, for example, be used to ensure that images pulled from any hosted repository meet a minimum set of security standards.

Repository-scoped policies are tailored to more-specific needs. For example, a specific repository used exclusively for internal testing purposes may permit images containing a larger number of vulnerabilities to be deployed. Acceptance of such risk is, of course, based on the assumption that these containers will never be exposed outside the organization — for example, deployed on a public cloud.

In combination with image signing and promotion, and with companion technologies like Content Trust, Helm chart static analysis and Running Image Enforcement let users build effective and nuanced security policies that reduce risk all along the software supply chain, without getting in the way of shipping good software faster.

Scanner Error Reporting

While MSR’s scanning is robust and reliable, it's well known that vulnerability detection for binary container images is not an exact science. Given the plethora of scanning options available, customers have, on occasion, reported dubious scanning results from MSR, or discrepancies between MSR CVE reports and those produced by other security tools. To assist forensics in such situations, Secure Registry now lets users report scanning result discrepancies to Mirantis, along with appropriate diagnostic information.

Scanning errors can now be reported to Mirantis for quick analysis and recommendations.

This feature can be accessed from the MSR UI’s vulnerability listing section. Along with automated collection of basic diagnostic information, it also lets you specify issue details and add comments to help Mirantis identify the source of problems.

Mirantis can then quickly analyze reports and take appropriate action to mitigate flaws in Secure Registry scanning, or identify steps you can take to reduce the frequency of errors you're experiencing.

Try Mirantis Secure Registry 2.9.0 Today

Mirantis Secure Registry 2.9.0 delivers important security and policy management benefits, easily leveraged by modern development teams. Evaluating Secure Registry is also simple. As noted above, our download recipe uses the Mirantis Launchpad deployer to create a three-node (one controller, two workers) Kubernetes Engine cluster, then uses the Docker CLI on one worker to install Secure Registry. The recipe runs well on medium-sized virtual machines in a home lab (e.g., on VirtualBox), or on a few VMs spun up on any handy public cloud.