Harbor inventory should pair project roles with registry authentication
Harbor adds user management, role-based access, scanning, signing, and project controls to a container registry. A publicly visible Harbor host may be intended to serve image pulls. The security question is which projects are visible, which tokens can push or delete artifacts, and whether the registry and authentication endpoints apply the same authorization decision.
A count-only ZoomEye SDK query for app="Harbor" returned 57,479 matches on 2026-10-28 at 18:47:58 UTC. The measurement used sub_type=all, page 1, and one record. It is a product-fingerprint total, not a count of public projects, leaked images, or vulnerable registries.
The query link preserves the evidence. Use it with the collection time and verify ownership before testing repository access.
Map authentication to project roles
Harbor project roles apply within a project. The external identity source may be a local database, LDAP or Active Directory, or OIDC. An administrator should know which authentication mode each instance uses and how a user or group is mapped to a project role. A broad system administrator should not be required for routine repository operations.
Review public versus private project visibility separately from robot accounts and user roles. A project can be intentionally public for distribution while push and delete operations remain restricted. A private project can still be exposed through a repository mirror, a cached artifact, or a credential in another system.
Review registry tokens and robot accounts
Container registries commonly use bearer-token exchanges. Docker's registry authentication documentation describes a token service that issues a scoped token after authenticating the client. Harbor's integration should be checked so that a pull token cannot push, delete, or cross into unrelated projects.
Create a separate robot or service account for each consumer. Record its project, operations, expiration, and owner. Remove old accounts after a pipeline migration. A token embedded in a cluster secret or CI variable should be rotated after that workload is retired.
Inspect artifact trust
Harbor can store and manage container images and OCI artifacts. Scanning is useful, but a clean scan does not prove that an image came from a trusted publisher. Use signing and provenance policy where the deployment supports it. Verify that a consumer validates the identity and digest it expects.
Limit who can delete tags and images. A delete action can break deployments or remove evidence needed for an incident. Protect retention policies and the storage layer separately from the web interface. Backups should preserve artifact digests and signatures where the product's metadata requires them.
Reduce accidental public reach
If only specific projects need anonymous pulls, separate that access from the administrative UI and push endpoints. Put management paths behind an organization gateway, use TLS, and test direct node addresses as well as the published hostname. Review redirects and authentication callbacks for open-redirect and host-header mistakes.
Monitor authentication failures, token issuance, robot-account changes, project visibility, and artifact deletion. A burst of pull-token requests can be normal scaling, but a new token used from an unexpected network deserves review.
The 57,479 matches are an inventory starting point. The useful output is a project map that links each Harbor instance to its authentication mode, role assignments, registry tokens, artifact policy, and owner. That map turns a broad product count into a set of concrete authorization decisions.
Top comments (0)