Infrastructure Security

Harbor Registry Security Configuration: A Complete Hardening Guide

Harbor is the most popular open-source container registry. Its security features are powerful but require deliberate configuration to be effective.

Yukti Singhal
Security Researcher
6 min read

Harbor has become the de facto standard for self-hosted container registries. It is a CNCF graduated project used by thousands of organizations to store and distribute container images. Out of the box, Harbor provides basic functionality. But its security features, which are among the best in any registry, require deliberate configuration to deliver their full value.

This guide walks through the security configurations that matter, starting with the ones most teams skip.

Authentication and Access Control

Configure External Authentication

Harbor supports local database authentication, LDAP/Active Directory, and OIDC providers. For anything beyond a proof of concept, use external authentication:

OIDC integration with your corporate identity provider gives you centralized user management, MFA enforcement, and automatic deprovisioning when employees leave. Configure OIDC in Harbor's administration panel under Configuration, then Authentication.

Implement Project-Level RBAC

Harbor's RBAC model operates at the project level. Each project can have different members with different roles: Project Admin, Developer, Guest, and Limited Guest.

The most common mistake is making everyone a Project Admin because it is convenient. Instead, follow least privilege. Developers who push images get the Developer role. CI/CD service accounts that only pull images get the Limited Guest role. Human administrators get Project Admin.

Use Robot Accounts for Automation

Do not use personal accounts in CI/CD pipelines. Create robot accounts with specific, scoped permissions. A build pipeline needs push access to one project. A deployment pipeline needs pull access to one or more projects. Create separate robot accounts for each use case.

Robot accounts have configurable expiration. Set reasonable expiration periods and rotate them as part of your credential management process.

Vulnerability Scanning

Harbor integrates with vulnerability scanners to check images on push, on schedule, or on demand. The built-in Trivy integration provides good coverage, but configuration matters.

Enable Scan on Push

Configure each project to scan images automatically when they are pushed. This catches vulnerabilities before they can be deployed:

Navigate to the project settings and enable "Automatically scan images on push." This is not enabled by default.

Set Vulnerability Thresholds

Harbor can prevent pulling images that exceed a vulnerability severity threshold. This is one of its most powerful features and one of the least used.

In project settings, enable "Prevent vulnerable images from running" and set the severity threshold. Setting it to High means images with High or Critical vulnerabilities cannot be pulled. This enforcement happens at the registry level, before the image reaches any deployment tool.

Schedule Regular Scans

New vulnerabilities are discovered daily. An image that was clean when it was pushed might have critical vulnerabilities a week later. Schedule regular scans across all projects to catch newly disclosed vulnerabilities:

Configure scan schedules under Administration, then Interrogation Services.

Content Trust and Signing

Harbor supports Docker Content Trust (DCT) through its integration with Notary. When content trust is enabled, only signed images can be pulled from the project.

Enable content trust at the project level under the project's Configuration tab. Once enabled, unsigned images in that project cannot be pulled. This requires that your build pipeline signs images as part of the push process.

For environments adopting Cosign, Harbor v2.5 and later supports Cosign signature verification through its built-in Cosign support. Configure Cosign verification policies to validate signatures against expected public keys or keyless identities.

Network Security

TLS Configuration

Harbor should always run with TLS. Self-signed certificates are acceptable for internal use but require distributing the CA certificate to all Docker clients and Kubernetes nodes that pull from the registry.

For production, use certificates from your internal CA or a public CA. Configure TLS in harbor.yml before installation:

https:
  port: 443
  certificate: /path/to/cert.pem
  private_key: /path/to/key.pem

Network Policies

Restrict network access to Harbor's components. The Harbor core, database, Redis cache, registry backend, and Trivy scanner should communicate only with each other and with authorized clients. Use Kubernetes NetworkPolicies or firewall rules to enforce this.

Proxy Cache Configuration

Harbor can function as a proxy cache for upstream registries like Docker Hub. This reduces your exposure to Docker Hub rate limits and provides a local cache that continues to serve images if the upstream is unavailable.

When using proxy cache, ensure that cached images are scanned by Harbor's vulnerability scanner. A cached image from Docker Hub might have vulnerabilities that your scanning policy would normally catch.

Replication Security

Harbor's replication feature copies images between Harbor instances or between Harbor and other registries. This is useful for multi-region deployments and disaster recovery.

Encrypt Replication Traffic

All replication connections should use TLS. Verify that replication endpoints are configured with HTTPS URLs and that certificate verification is enabled. Disabling certificate verification to work around self-signed certificate issues is a common shortcut that opens you to man-in-the-middle attacks.

Scope Replication Rules

Replicate only the images that need to be in each location. A replication rule that copies everything from one Harbor to another duplicates all vulnerabilities along with the images. Use filters to replicate only specific projects, repositories, or tags.

Garbage Collection and Retention

Configure Tag Retention

Without retention policies, Harbor accumulates every image ever pushed. Old images with known vulnerabilities remain pullable indefinitely. Configure tag retention policies to automatically remove old images while preserving a defined number of recent versions.

Run Garbage Collection

Deleting images through Harbor's UI or API marks layers for deletion but does not reclaim storage. Run garbage collection regularly to actually remove deleted layers from the storage backend. Schedule garbage collection during off-peak hours.

Audit Logging

Harbor logs all operations: image push, pull, delete, scan results, project changes, and authentication events. Forward these logs to your SIEM or log aggregation system.

Key events to alert on include pulls of images with known critical vulnerabilities, new robot account creation, project permission changes, failed authentication attempts, and changes to vulnerability scanning configuration.

How Safeguard.sh Helps

Safeguard.sh complements Harbor's built-in security features by providing deeper supply chain analysis. While Harbor scans images for known CVEs, Safeguard.sh generates comprehensive SBOMs, tracks dependency relationships across your entire image inventory, and identifies supply chain risks that go beyond individual vulnerabilities. When you need to understand the blast radius of a newly disclosed CVE across all your Harbor projects, Safeguard.sh provides that visibility instantly.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.