Scoping Harbor Access: Restricting Image Visibility via Projects and RBAC

Is your container registry too open? Restricting image visibility in Harbor requires leveraging Projects and Role-Based Access Control (RBAC).

The core challenge in using Harbor isn't just storing images; it's ensuring only authorized teams can see, pull, or push specific artifacts. The useful takeaway is that Harbor's Project scoping, combined with granular RBAC, provides the necessary isolation without needing complex network segmentation.

Project Isolation for Team Boundaries

In Harbor, a Project acts as a logical boundary, grouping related repositories (where images live). This boundary is the first line of defense for visibility. By placing sensitive application images in a dedicated project, you automatically restrict access to that project's contents.

Granular Control with RBAC

Role-Based Access Control (RBAC) defines what a user or group can do (e.g., push, pull, admin) within a specific Project. Authentication methods like LDAP or OIDC handle who the user is; RBAC dictates what they can do within the Harbor environment.

Example: Restricting Access to Production Images

Suppose you have a production-app project and only the deployment-team should push or pull from it. You configure the deployment-team group (mapped via LDAP/OIDC) to have the push and pull roles assigned specifically to the production-app project, while other groups (like qa-team) are only granted pull access to that same project.

# Action taken in Harbor Admin UI:
# 1. Navigate to 'production-app' Project settings.
# 2. Assign 'deployment-team' group the 'push' role.
# 3. Assign 'qa-team' group the 'pull' role.
# 4. Verify no other roles are assigned to these groups within this project scope.

Trade-off: Configuration Complexity

While powerful, RBAC complexity scales non-linearly. Managing dozens of roles across many projects demands disciplined governance. Over-permissioning (giving too much access) is easier than correctly restricting access across a large fleet.

Verification and Limitations

To practically check this, attempt to pull an image from the production-app project using a user account belonging to the qa-team. The operation must fail with an authorization error, not a network or repository-not-found error. Limitation: Harbor's project scoping is logical; it does not replace network firewalls for ingress/egress control.

Actionable step: Audit your existing projects. If a project contains artifacts for multiple, distinct teams, consider splitting it into sub-projects to enforce stricter RBAC boundaries.