Harbor is an open-source container registry that provides storage, signing, and scanning of container images. Built by VMware and now a CNCF graduated project, Harbor adds enterprise features on top of the Docker Distribution registry – including role-based access control (RBAC), vulnerability scanning, image replication, and audit logging. If you run Harbor in a shared environment, one of the first things you should lock down is who can create projects. By default, any authenticated user can spin up new projects, which leads to sprawl and makes governance painful. This guide walks through restricting project creation to administrators only, configuring RBAC roles properly, and setting up additional controls like quotas and audit logging in Harbor 2.x.
Prerequisites
Before proceeding, make sure you have the following in place:
- A running Harbor 2.x instance (2.9 or later recommended)
- Administrator access to the Harbor web portal
- A working understanding of container registries and Docker/Podman basics
- If using external authentication (LDAP or OIDC), that integration should already be configured and tested
Understanding Harbor Projects
In Harbor, a project is the fundamental organizational unit. Every container image belongs to a project. When you push an image like harbor.example.com/backend/api-server:v2.1, the “backend” portion is the project name. Projects control access policies, vulnerability scan settings, robot accounts, webhooks, and storage quotas. Letting every user create projects without oversight leads to duplicate repositories, inconsistent naming, and storage bloat. In production environments, you want a controlled process where an administrator provisions projects and assigns team members with appropriate roles.
Configure Project Creation Policy to Admin-Only
Harbor ships with a global configuration option that controls whether all authenticated users can create projects or only administrators. Here is how to restrict it.
Method 1 – Using the Web Portal
Log in to the Harbor portal as an administrator. Navigate to Administration then Configuration. Select the System Settings tab. Look for the Project Creation setting. Change it from Everyone to Admin Only. Click Save to apply the change.
Once saved, non-admin users will no longer see the “New Project” button in the web UI, and API calls to create projects from non-admin accounts will return a 403 Forbidden response.
Method 2 – Using the Harbor API
You can also set this via the Harbor v2.0 API. This is useful for automation or if you manage Harbor through infrastructure-as-code pipelines.
curl -X PUT "https://harbor.example.com/api/v2.0/configurations" \
-H "Content-Type: application/json" \
-u "admin:YourAdminPassword" \
-d '{"project_creation_restriction": "adminonly"}'Verify the configuration was applied:
curl -s "https://harbor.example.com/api/v2.0/configurations" \
-u "admin:YourAdminPassword" | jq '.project_creation_restriction'The output should return:
"adminonly"Understanding RBAC Roles in Harbor
After restricting project creation, you need to understand how Harbor’s role-based access control works so you can assign the right permissions to each team member. Harbor defines roles at two levels – system level and project level.
System-Level Roles
- Harbor System Administrator – Full control over all projects, users, registries, replications, and system configuration. This is the role that retains the ability to create projects when project creation is restricted.
- Regular User – Can be added to specific projects with a project-level role. Cannot access system administration features.
Project-Level Roles
- Project Admin – Manages members and settings within a single project. Can add or remove users, configure vulnerability scanning policies, and manage robot accounts for that project. Cannot create new projects when restricted.
- Maintainer – Can push, pull, delete images, and scan artifacts. Cannot manage project membership.
- Developer – Can push and pull images. Cannot delete images or modify project settings.
- Limited Guest – Can pull images only. Cannot browse the project through the web UI.
- Guest – Can pull images and browse the project in the UI, but cannot push or modify anything.
When you create a project as an admin, assign each team to the minimum role they need. CI/CD service accounts typically need Developer or Maintainer. Deployment systems that only pull images should use Guest or Limited Guest.
Managing Access with OIDC and LDAP Groups
Manually adding individual users to each project does not scale. Harbor supports group-based membership through both LDAP and OIDC providers. This lets you map existing directory groups directly to Harbor project roles.
LDAP Group-Based Access
If Harbor is configured with LDAP authentication, navigate to a project and click Members, then + Group. Enter the LDAP group DN, for example cn=backend-devs,ou=groups,dc=example,dc=com, and assign it a project role such as Developer. Every member of that LDAP group now inherits the Developer role in that project. When someone leaves the team and is removed from the LDAP group, they automatically lose access to the Harbor project – no manual cleanup needed.
OIDC Group-Based Access
For OIDC providers like Keycloak, Azure AD, or Okta, Harbor reads group claims from the OIDC token. In the Harbor system configuration under the OIDC section, set the Group Claim Name field to the claim that contains group information in your ID token (commonly groups or roles). Then, when adding a group member to a project, enter the group name exactly as it appears in the OIDC token claim. Harbor will match the group claim at login time and grant the configured role automatically.
This approach is strongly recommended for organizations with more than a handful of users. It eliminates manual user management and ensures that access follows your identity provider’s group structure.
Enable and Review Audit Logging
After tightening access controls, you need visibility into what users are actually doing. Harbor maintains an audit log that records events such as image pushes, pulls, deletions, project creation, and membership changes.
To view audit logs, navigate to Administration then Audit Log in the Harbor portal. You can filter by username, resource type, and time range. For long-term retention, configure Harbor to forward audit logs to an external syslog endpoint. In the harbor.yml configuration file, set the external log endpoint:
log:
level: info
external_endpoint:
protocol: tcp
host: syslog.example.com
port: 514After modifying harbor.yml, re-run the installer to apply changes:
sudo ./install.shVerify that logs are arriving at your syslog server by pushing a test image and checking for the corresponding event.
Set Storage Quotas Per Project
Even with project creation locked down, you should set storage quotas to prevent any single project from consuming all available disk space. Harbor supports per-project quotas that limit the total storage consumed by all artifacts in a project.
To set a quota, navigate to the project, click Configuration, and set the Storage Quota value. For example, setting it to 10 GiB means the project cannot store more than 10 GiB of image layers. Pushes that would exceed the quota are rejected with an error.
You can also set a default quota for all new projects via the API:
curl -X PUT "https://harbor.example.com/api/v2.0/configurations" \
-H "Content-Type: application/json" \
-u "admin:YourAdminPassword" \
-d '{"storage_per_project": 10737418240}'The value is in bytes – 10737418240 equals 10 GiB. Set this to -1 for unlimited (not recommended in shared environments).
Verification
After applying all these changes, verify the setup by performing the following checks:
- Log in as a non-admin user and confirm the “New Project” option is not available in the UI.
- Attempt to create a project via the API as a non-admin user and confirm you receive a 403 response.
- Add a test user to a project with the Guest role and confirm they can pull but not push images.
- Check the audit log to verify that your test actions were recorded.
- Push images to a project with a quota and confirm the quota usage increases in the project summary.
Summary
Locking down project creation in Harbor is a straightforward configuration change, but it should be part of a broader access control strategy. Set the project creation policy to admin-only, assign RBAC roles following the principle of least privilege, use LDAP or OIDC groups to manage membership at scale, enable audit logging for accountability, and apply storage quotas to prevent resource abuse. These controls together give you a well-governed container registry that supports multiple teams without turning into a management headache.
