What’s changed in MSR¶
Mirantis Secure Registry (MSR) 4 is now based on CNCF Harbor, bringing increased stability, improved feature sets, and a broader ecosystem of integrations. This document outlines key changes, migration paths, and considerations for customers transitioning from MSR2 or MSR3 to MSR4.
Key Differences and Feature Changes¶
Since MSR4 is built on a new codebase, customers will observe functional differences compared to MSR2 and MSR3. These changes impact exportable metrics, job runner operations, webhooks, and API access methods. Below are the most notable changes:
Authentication and Access Control¶
SAML Authentication
MSR4 uses OpenID instead of legacy SAML. For MSR4 and cloud-native applications, OIDC is the better choice due to its lightweight nature, modern API compatibility, and stronger support for mobile, and microservices architectures. If a customer is still using SAML for authentication, they might need an Identity Provider (IdP) that bridges SAML and OIDC (e.g., Okta, Keycloak, or Azure AD). Open ID has broader support with the Enterprise and Cloud Identity Providers (IdPs) supporting Azure AD, Okta, Google Identity Platform, Amazon Cognito, Ping Identity, IBM Security Verify, OneLogin, and VMware Workspace ONE.
Teams RBAC
MSR4 does not include MSR2/3 Teams or Enzi. Customers can manually add individual users to projects. Group permissions are available only through AD Groups which requires LDAP/AD and OIDC authentication.
Artifact Management and CI/CD Pipelines¶
Helm Support
Upstream Harbor is changing in favor of OCI registries which supports OCI Helm.
Both Harbor and Helm CLI can manage charts as OCI artifacts, but Helm CLI
search functionality is currently limited. Searching through the Harbor UI
remains fully supported, and the upcoming Harbor CLI tool may introduce
artifact search capabilities.
In Harbor, Helm charts are managed as OCI artifacts rather than using a
dedicated Helm repository. Traditionally, Helm stored charts in a proprietary
Helm Chart Repository, which allowed direct Helm CLI interactions such as
helm search repo and helm show. With OCI-based Helm storage, charts are
pushed and pulled using standard OCI commands (helm push oci:// and helm
pull oci://), aligning with container registry best practices.
However, this shift introduces some functional differences: searching for charts using helm search repo is no longer possible, requiring users to rely on the Harbor UI or future enhancements in the Harbor CLI. The change to OCI-based Helm storage improves interoperability with OCI-compliant registries but requires minor workflow adjustments for Helm users accustomed to traditional chart repositories.
Promotion Policies
Promotion Policies are not formally supported in Harbor. Customers relying on Promotion Policies should consider modifying their CI/CD pipelines.
Deployment and Infrastructure Support¶
Swarm Support
Upstream Harbor does not support Swarm. Customers running Swarm are advised to deploy MSR4 as a single-node instance using Docker Compose. For high availability (HA) deployments, Kubernetes is required. Most customers with HA demands typically have Kubernetes in their environments and can leverage it for MSR4.
Backup and Disaster Recovery
In MSR2 and MSR3, backup functionality was built-in, allowing customers to create and restore backups easily. MSR4 introduces a different approach where backups must be managed externally using Velero, an open-source backup tool widely used in enterprise environments, including on platforms like Azure. Unlike the previous versions, which handled backups natively, Velero requires a Kubernetes-based deployment.
Future MSR4 (Harbor) Upgrades¶
One of the key improvements with MSR4 is the ability to perform in-place upgrades with significantly shorter maintenance windows, in contrast, MSR2 and MSR3 which necessitated scheduling large maintenance windows. Moving forward, upgrades in the MSR4.x series will be faster, more efficient, and require minimal downtime.
What Upgrades Automatically to MSR4¶
CNCF Harbor (MSR4) fully supports mirroring migration from MSR2 and MSR3, allowing customers to seamlessly transfer:
Images
Helm Charts
Tags
Repository structure
A key advantage of this migration process is the ability to use mirroring, which reduces the need for extended maintenance windows previously required by MMT. With mirroring, both MSR2/3 and MSR4 can remain active, minimizing disruption and allowing teams to update their pipelines while maintaining system availability.
MSR4 also supports migration from other registry platforms. For a full list of supported platforms and migration instructions, please refer to this artifact.
Summary¶
Migrating to MSR4 provides enhanced performance, improved upgrade processes, and a broader feature set. However, some functional differences require customers to adapt workflows, particularly around authentication, promotion policies, and backup strategies. Customers should review the outlined differences and plan their migration accordingly.
For further details, refer to the full documentation on this site or contact Mirantis Support.