Harbor
Harbor is an open-source registry for container images and other Open Container Initiative artifacts. It adds access control, security checks, replication, and lifecycle management around the storage used by build and deployment systems.
itCloud native tools and technologies | OpenSkills.info
Intro
Harbor
A container registry connects software production to software deployment. Build systems push artifacts into it. Container runtimes and deployment platforms pull those artifacts later. The registry therefore becomes a control point for availability, identity, integrity, and software supply chain policy.
Harbor is an open-source, cloud-native registry for container images and other Open Container Initiative artifacts. It builds a management and security layer around a Distribution registry. Harbor adds projects, role-based access control, robot accounts, vulnerability scanning, artifact signing integrations, replication, proxy caching, audit logs, quotas, and lifecycle policies.
This course gives you a working mental model of Harbor. You will understand where it belongs in a delivery system, how its components cooperate, which controls protect artifacts, and which operational duties remain with you.
The registry as a controlled handoff
Treat Harbor as the boundary between producers and consumers:
source → build → sign → push → Harbor project → scan and policy → pull → runtime
A producer creates an artifact and addresses Harbor through a standard registry client. Harbor authenticates the identity, checks authorization for the target project, and issues a scoped token when the request is allowed. The registry stores artifact content in its storage backend. Harbor stores project, policy, user, scan, and replication metadata in PostgreSQL.
A consumer later requests an artifact by tag or digest. Harbor applies project access and configured deployment policies before the registry serves the content. This central position lets platform teams apply consistent controls without requiring every build and runtime to implement a separate registry service.
Harbor stores artifacts. It does not build container images, schedule workloads, or decide whether application code is safe. Those jobs belong to build tools, deployment platforms, and your security process.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://goharbor.io/docs/main/
Supports
- Harbor v2.15 documentation scope and current operational categories
- Installation, administration, project, and contributor learning path
- https://github.com/goharbor/harbor
Supports
- Harbor as an open-source cloud-native registry that stores, signs, and scans content
- Distribution foundation, role-based access, replication, audit, portal, API, and deployment features
- Harbor project release and security resources
- https://github.com/goharbor/harbor/wiki/Architecture-Overview-of-Harbor
Supports
- OCI artifact support and registry client interactions
- Proxy, core, token service, registry, job service, portal, PostgreSQL, Redis, and storage responsibilities
- Authentication, authorization, token issuance, scanning, replication, and artifact metadata flow
- https://goharbor.io/docs/main/install-config/
Supports
- Docker Compose and Helm deployment paths
- HTTPS, configuration, lifecycle, and troubleshooting responsibilities
- https://goharbor.io/docs/main/install-config/configure-yml-file/
Supports
- Hostname, HTTPS, storage backend, external PostgreSQL, external Redis, job worker, metrics, tracing, and logging configuration
- Relationship between Harbor components and external dependencies
- https://goharbor.io/docs/main/install-config/harbor-ha-helm/
Supports
- Multiple replicas for stateless Harbor components
- Highly available ingress, PostgreSQL, Redis, and shared persistent or object storage requirements
- Helm deployment model for Harbor on Kubernetes
- https://goharbor.io/docs/main/working-with-projects/create-projects/
Supports
- Projects as repository groups and role-based access boundaries
- Public and private project pull behavior
- Requirement to create a project before pushing an image
- https://goharbor.io/docs/main/working-with-projects/project-configuration/
Supports
- Public and private project configuration
- Scan-on-push and vulnerability-severity pull prevention
- Project build-history and security settings
- https://goharbor.io/docs/main/working-with-projects/project-configuration/create-robot-accounts/
Supports
- Project robot accounts for non-human OCI client and API automation
- Project scope, permissions, expiration, secret export, refresh, and interface restrictions
- Difference between project and system robot accounts
- https://goharbor.io/docs/main/working-with-projects/working-with-oci/
Supports
- Harbor workflows for OCI artifacts including OCI Helm charts and user-defined artifacts
- https://goharbor.io/docs/main/working-with-projects/working-with-images/create-tag-immutability-rules/
Supports
- Difference between movable tags and stable digests
- Project-level immutability rules and protected artifact behavior
- Immutability across push, retag, delete, and replication operations
- https://goharbor.io/docs/main/working-with-projects/working-with-images/create-tag-retention-rules/
Supports
- Repository, quantity, age, pull, and tag retention criteria
- Retention dry runs, schedules, rule behavior, and irreversible execution warning
- Interaction among artifact tags, retention, and quotas
- https://goharbor.io/docs/main/administration/vulnerability-scanning/
Supports
- Manual, bulk, and scheduled vulnerability scans
- Multiple scanner adapters and variation among vulnerability data and severity
- Vulnerability report export and offline vulnerability-data import
- https://goharbor.io/docs/main/working-with-projects/working-with-images/sign-images/
Supports
- Harbor integration with Cosign and Notation
- Artifact signatures as accessories and project content-trust enforcement
- Signing and verification workflow for artifact digests
- https://goharbor.io/docs/main/administration/configuring-replication/create-replication-endpoints/
Supports
- Remote registry provider, URL, credential, certificate, and connection configuration
- Least-privilege and trusted-upstream considerations
- Harbor and supported non-Harbor replication endpoints
- https://goharbor.io/docs/main/administration/configuring-replication/create-replication-rules/
Supports
- Push and pull replication, filters, destination namespace, and override behavior
- Manual, scheduled, and event-based triggers
- Replication execution and concurrency controls
- https://goharbor.io/docs/main/administration/configure-proxy-cache/
Supports
- Pull-triggered retrieval and caching of upstream registry content
- Trusted endpoint, least-privilege credential, and proxy project retention guidance
- Difference between proxy caching and explicit replication
- https://goharbor.io/docs/main/administration/garbage-collection/
Supports
- Artifact deletion not immediately freeing storage
- Removal of blobs no longer referenced by manifests
- Dry run, scheduling, execution history, and task behavior
- https://goharbor.io/docs/main/administration/
Supports
- Authentication, quotas, replication, scanning, metrics, tracing, audit, cleanup, backup, and upgrade responsibilities
- Harbor system administrator operating scope
- https://goharbor.io/docs/main/administration/audit-log/
Supports
- Audit records for artifact, user, configuration, project, and robot actions
- Audit querying, forwarding, and database storage choices
- https://goharbor.io/docs/main/administration/upgrade/
Supports
- Version-specific upgrade and migration planning
- Database schema migration and backup requirements
- https://github.com/sindresorhus/awesome
Supports
- Required starting point for awesome-list discovery
- Discovery of the Linux Containers and DevSecOps awesome lists
- https://github.com/Friz-zy/awesome-linux-containers
Supports
- Curated discovery of Skopeo, go-containerregistry, Buildah, and umoci
- Placement of those tools in the container image and registry ecosystem
- https://github.com/JakobTheDev/awesome-devsecops
Supports
- Curated discovery of Trivy, Sigstore, and Syft
- Placement of scanning, signing, and software bill of materials tools in DevSecOps
- https://github.com/podman-container-tools/skopeo
Supports
- Daemonless inspection, copying, deletion, and synchronization of registry images
- Remote registry authentication and OCI image support
- https://github.com/google/go-containerregistry
Supports
- Go libraries for container image and registry operations
- crane as a command-line tool for remote images and registries
- https://buildah.io/
Supports
- Building OCI container images without a full container runtime or daemon
- Current project release and learning resources
- https://umo.ci/
Supports
- OCI image layout modification, unpacking, repacking, tagging, configuration, and cleanup
- Command-line stability and quick-start documentation
- https://trivy.dev/docs/latest/getting-started/
Supports
- Container image vulnerability scanning
- Filesystem and Kubernetes scanning for vulnerabilities, secrets, and misconfigurations
- https://docs.sigstore.dev/
Supports
- Cosign signing and verification for container images and other artifacts
- Identity-based short-lived certificates and transparency-log evidence
- https://oss.anchore.com/docs/guides/sbom/
Supports
- Software bill of materials generation from images, registries, directories, files, and archives
- SPDX, CycloneDX, native JSON, and attestation workflows