Multi-Tenancy via OIDC and RBAC: Granular Access Control in Enterprise Registries

In the early stages of container projects, things are usually simple: A small development team builds a handful of microservices, shares a common access to the container registry, and pushes all images into one large, open repository. However, as the containerized infrastructure within a company grows, multiple departments work on clusters in parallel, or external service providers and agencies are integrated into the CI/CD pipelines, this unregulated model reaches dangerous limits.

When everyone involved can see, modify, or delete everything, the next serious configuration error or security incident is just a matter of time. Enterprise environments and highly regulated industries (under guidelines like NIS-2 or DORA) require strict, logical separation of projects and teams, true multi-tenancy. The architectural challenge is to represent this isolation at the central container registry without creating a new data silo for each team. The tool of choice is the seamless integration of OpenID Connect (OIDC) and role-based access control (RBAC) directly based on Harbor.

The Problem: The “All-or-Nothing” Dilemma in Access

Many simple or proprietary registry services often offer only very coarse rights management. Either all systems authenticate via global administrator tokens, or access control is completely neglected.

This lack of granular isolation results in three significant risks in enterprise practice:

1. The Risk of Accidental Overwriting (Image Poisoning)

If Team A (Finance) and Team B (Logistics) operate in the same unstructured IP space, a misconfiguration in Team B’s CI/CD pipeline can lead to an image from Team A being accidentally overwritten. Since Kubernetes blindly requests the changed image at the next pod restart, unpredictable outages occur in Team A’s production environment.

2. Unauthorized Leakage of Intellectual Property (Data Leakage)

External development service providers necessarily require access to the registry to push base images. If the registry lacks true multi-tenancy, external employees may, in the worst case, also view the repositories of the internal core development and unauthorizedly copy sensitive source codes or proprietary algorithms.

3. The “Token Chaos” in Identity Management

If passwords and access tokens for the registry must be manually created, distributed, and regularly rotated in the provider’s web interface, IT security quickly loses track. When an employee leaves the company or a service provider is terminated, orphaned access data often remain active in the systems for months because there is no central deactivation.

The Architecture of Isolation: Harbor Projects Controlled by OIDC

A sovereign and multi-tenant registry architecture breaks with manual account management. It shifts authentication to the company’s central Identity Provider (IdP) and enforces authorization through Harbor’s logical project concept.

[ Developer / CI/CD Pipeline ]
               |
               v (Login request via OIDC)
   [ Central Identity Provider ] <--- (Active Directory / Okta / Keycloak)
               |
               v (Issuance of a signed JWT token including groups)
[ Managed Harbor Container Registry ]
               |
      (Checking RBAC roles in the target project)
               |
         +-----+-----+
         |           |
         v           v
[ Project 'Finance' ] [ Project 'Logistics' ]
 (Only Finance group)  (Only Logistics group)

1. Central Authentication via OIDC

No one logs in with a local Harbor password anymore. The container registry is directly linked to the company’s leading identity system via OpenID Connect (OIDC) (e.g., Keycloak, Okta, Microsoft Entra ID, or a local Active Directory). During login, the user authenticates with this central IdP. After successful verification, Harbor receives a cryptographically signed JSON Web Token (JWT), which contains not only the user’s identity but also their group memberships.

2. Logical Isolation through Harbor Projects

In Harbor, each repository is necessarily assigned to a project (e.g., registry.ayedo.de/finance/api). A project forms the logical isolation boundary. Each project has its own storage quotas, its own security policies for CVE scanning, and - most importantly - its own dedicated RBAC table.

3. Role-Based Authorization (RBAC) in Practice

Instead of laboriously configuring permissions for each individual user manually, Harbor assigns fixed roles within projects to the corporate groups transmitted via OIDC. Harbor offers standardized, granular roles for this:

• Project Admin: Can manage repositories, define scanner policies, and control access rights within the project.
• Developer: Has full write and read rights (push and pull) to manage images in the project.
• Guest: Can only read images (pull), but cannot make any changes, ideal for integrating Kubernetes clusters via imagePullSecrets.

Strategic Added Value: The Zero-Trust Principle in the Supply Chain

The consistent implementation of OIDC and RBAC at the registry provides the commercial and technical security that modern Cloud-Native platforms require:

• Central “Kill Switch” for IT Security: If an employee leaves or a pipeline is compromised, a single block in the central identity provider is sufficient. Access to the container registry is revoked worldwide in the same instant - without having to touch passwords in Harbor.
• Guaranteed Tenant Separation (Compliance-ready): For multi-tenant environments where an IT department acts as an internal service provider for various subsidiaries, the project concept provides the legally secure proof of data separation according to GDPR and ISO 27001.
• Secure Automation via Robot Accounts: For CI/CD pipelines that must operate purely mechanically, Harbor uses so-called Robot Accounts. These short-lived, precisely restricted token connections are issued exactly for a specific project and a defined action (e.g., only push in the logistics project). They prevent a compromised pipeline from endangering the entire system.

Conclusion: Identity is the New Network Perimeter

In modern enterprise operations, the IP address as the sole security feature is long outdated. True network security and resilience arise when identity and the associated rights are unassailably verified at every interface. The combination of OIDC centralization and Harbor’s powerful RBAC project model transforms the container registry from a simple storage location into a highly secure, multi-tenant governance platform. It gives IT managers absolute control over who brings which code into the infrastructure and lays the unshakeable foundation for a seamlessly auditable software supply chain.

FAQ: RBAC & OIDC in Practice

Can we still use Docker CLI commands on the command line despite OIDC integration?

Yes, absolutely. Since the Docker CLI and tools like containerd do not natively support the interactive OIDC login procedure (OAuth2 web flows) on the command line, Harbor offers an elegant feature called CLI Secrets. After successful login via the web interface, the developer can generate a personal, long-lived CLI password. This is then used for the classic docker login command. Alternatively and preferably, dedicated Robot Accounts are used for CI/CD pipelines.

What happens to the rights in Harbor if a group membership changes in Active Directory?

The rights are dynamically updated. Since Harbor validates the transmitted OIDC token and reads the group memberships contained therein with every API request, changes in the central IdP take effect immediately. If an employee is removed from the “Developer-Finance” group in Active Directory, they lose their write rights in the Harbor project “Finance” at the same moment without any delay.

Does Harbor also support granular rights for deleting images?

Yes. The RBAC model allows precise control over who has the right to physically delete container tags or entire repositories. In practice, this permission is usually granted restrictively (only to Project Admins) to prevent developers or automated scripts from deleting historical image states needed by older, still active pods in the Kubernetes cluster in the heat of the moment.