01 · Why a registry matters
Kubernetes can schedule a container only after it can obtain the image.
Every deployment begins with an image reference. But downloading an image is not the same as trusting it. Production teams need to know who published it, which version is approved, whether it has known vulnerabilities, where it is stored, and who is allowed to pull it.
Without a shared registry strategy, each team makes local choices such as public registries, personal credentials, different scanning practices, inconsistent retention and unclear ownership. That may work for a small experiment. It becomes difficult to defend in a regulated platform with many teams.
Harbor is not merely a place to push images. In VKS, it can be the controlled handoff point between software delivery and workload execution.
02 · What Harbor adds
Harbor is an OCI registry with the operational controls that a shared platform needs.
At its core, Harbor stores OCI compatible container images and artifacts. The enterprise value comes from the controls around that content. Projects, role based access, external identity integration, robot accounts, vulnerability scanning, signing, replication, auditability and quotas all matter when the registry becomes shared infrastructure.
For application teams
A predictable repository endpoint, project access and machine credentials for CI/CD. Teams can publish and pull their own approved images without operating registry infrastructure.
For platform and security teams
A central policy and lifecycle point for image content where identity, scanning, retention, replication, capacity, monitoring and incident response can be operated consistently.
That does not mean every image must be centrally controlled in the same way. The platform can use separate Harbor projects, quotas, role bindings and policies to give teams autonomy within a defined boundary.
03 · Do not mix up the content types
Application images and VKS Standard Packages both use OCI distribution, but they serve different consumers.
| Content | Consumer | Purpose | Typical owner |
|---|---|---|---|
| Application container image | VKS workload | Runs an application component | Application team |
| VKS Standard Package and add on content | VKS cluster or platform workflow | Adds a supported Kubernetes capability | Platform or cluster team |
| Supervisor Service artifact | Supervisor | Delivers a VCF governed platform service | Cloud admin or platform team |
Harbor can host private OCI content, including application images and content required by private package workflows. However, do not state that VKS Standard Packages are always stored in the same Harbor instance that serves application teams. VKS can use Broadcom provided registries, Regional Harbor or another private OCI registry. In VCF 9.1, Regional Harbor is the VCF Automation managed pattern for hosting platform service content such as Supervisor Services, VCF CLI plugins and VKS Standard Packages.
04 · Choose the delivery model deliberately
“Use Harbor” is not yet an architecture decision.
| Model | Where it runs or scope | Use it when | Watch for |
|---|---|---|---|
| Harbor in a VKS workload cluster | Inside one workload cluster | A team needs a local registry pattern. | The cluster team owns availability, upgrades, storage and recovery. |
| Harbor as a Supervisor Service | Installed on the Supervisor and consumed as a governed platform capability | Several teams need one supported shared registry with central lifecycle ownership. | Contour, FQDN/DNS, TLS trust, persistent storage and operational ownership are prerequisites. |
| Regional Harbor through VCF Automation | VCF Automation managed regional service | The VCF platform needs centrally managed registry capability for Supervisor Services, VCF CLI plugins and VKS Standard Packages. | For service management integrated with VCF Automation in 9.1, validate the Regional Harbor or equivalent prerequisite and define content retention ownership explicitly. |
These models are not mutually exclusive. A large organisation may use Regional Harbor for VCF platform content, an independently operated shared Harbor or a Supervisor Service for internal application images, and a local registry for a specialised disconnected environment. The choice should follow ownership, reach, resilience and compliance needs. Convenience alone is not enough.
Deployment model Q&A
Questions architects ask after choosing the scope
The models can coexist, but each additional instance needs a clear purpose and operating owner.
Question 01Can all three Harbor models exist in the same VCF environment?+
Yes. For example, Regional Harbor can serve VCF platform artifacts and VKS Standard Packages, a shared Harbor deployment can serve application teams, and a cluster local Harbor can support a specialised isolated or disconnected use case. They are separate deployments, so define the content boundary and ownership for each.
Question 02Should every application team get its own Harbor instance?+
Usually no. Separate Harbor projects, RBAC, robot accounts, quotas and policies within a shared Harbor normally provide effective team isolation with far less operational overhead. Use a separate instance only for a real availability, recovery, latency, data residency or regulatory boundary.
Question 03Does Regional Harbor replace Harbor as a Supervisor Service?+
Not automatically. Regional Harbor is a VCF Automation managed regional platform registry for selected VCF artifacts, plugins, Supervisor Services and VKS Standard Packages. Harbor as a Supervisor Service can provide a shared, governed registry capability to application teams. Choose by consumers, scope and operating model.
Question 04Are VKS Standard Packages always stored in Harbor?+
No. VKS can use Broadcom provided registries, Regional Harbor or another private OCI registry. Harbor is a common choice where controlled private content, disconnected operations or a VCF managed Regional Harbor pattern is required.
Question 05What is a sensible starting point for several application teams?+
Start with one centrally operated registry pattern, either an independently operated Harbor or a supported Supervisor Service. Then separate projects and policies for each team. Complete the applicable DNS, TLS and CA trust, ingress, persistent storage, capacity, monitoring, backup and restore design before onboarding consumers. Add instances only when a stated requirement demands another boundary.
05 · Make Harbor ready for production before making it self service
A successful installation is not a service design.
Harbor becomes part of the path to production. Design it with the same care as any shared platform service that holds important data. The required implementation details follow the model selected in Section 4. Supervisor Service specifics are called out explicitly below.
Network and identity decisions
- Dedicated FQDN and DNS ownership
- TLS certificate lifecycle and CA distribution
- Ingress exposure and network policy
- OIDC/LDAP integration and emergency administration
- Robot account credential lifecycle for CI/CD
Data and resilience decisions
- Storage policy, performance tier and capacity headroom
- Project quotas and image retention policy
- Backup scope, restore runbook and restore testing
- Controlled replication, curated mirror or proxy cache design for locality and disconnected use
- Metrics, audit logs, alert thresholds and support ownership
When a private Harbor CA is used with the Supervisor Service pattern, the Supervisor must trust that CA before vSphere Pods and VKS clusters can pull images. Treat CA trust as a controlled platform change and follow the supported procedure for your VCF release.
“Harbor is deployed as Kubernetes containers” does not mean it is stateless. Registry blobs and supporting services need persistent data, a recovery plan and ongoing capacity management.
Enterprise integration Q&A
Fit Harbor into approved enterprise standards and tools
Harbor needs these capabilities. It does not require an organisation to replace an established enterprise service for every capability.
Question 01Does adopting Harbor mean we must introduce Contour, ExternalDNS, cert-manager or new infrastructure tools?+
No. Start with approved enterprise standards and tools for load balancing, DNS, certificates, identity, storage, monitoring, backup and security. The selected Harbor deployment model determines the documented dependencies and the level of flexibility available.
Question 02Can we use Harbor without Contour?+
Yes. Harbor itself does not require Contour. An independently operated Harbor can use a validated enterprise exposure design, such as F5, Avi Load Balancer, NGINX or another approved reverse proxy and load balancing pattern. For the documented Harbor as a Supervisor Service pattern, Contour remains part of the VCF deployment architecture. It is not a component to replace with another ingress product.
Question 03Can Harbor use existing DNS and PKI services?+
Yes. Harbor needs a stable FQDN that resolves for users, CI/CD systems and every cluster that pulls images. It also needs a TLS certificate whose CA chain is trusted by those consumers. DNS automation and Kubernetes certificate automation are options. They are not mandatory replacements for established enterprise DNS and PKI processes.
Question 04Can Harbor use existing storage, backup and monitoring platforms?+
Yes, provided the selected deployment model supports the integration and the design meets performance, availability, backup and restore objectives. For a critical registry, choose storage and recovery based on RPO, RTO and image pull performance, not merely on available capacity.
Question 05Can Harbor fit into current network and security controls?+
Yes. Define the access paths instead of bypassing them. Decide who pushes images, which clusters pull them, how CI/CD reaches Harbor, where firewall boundaries sit, and how TLS is terminated and inspected. Harbor should integrate with identity, vulnerability response, logging/SIEM, monitoring and incident management.
Question 06When is an independently operated Harbor a better choice than a Supervisor Service?+
Choose based on service criticality and ownership. A Supervisor Service is a strong VCF native choice when its supported architecture meets the requirements. An independently operated Harbor is often appropriate when the registry serves multiple platforms or needs a bespoke HA/DR, PKI, WAF, network, storage or operations model.
Question 07Will later blogs cover these integrations in depth?+
Yes. This article introduces the decisions around Harbor. Upcoming blogs will explore ingress and exposure, DNS, certificates and trust, storage, networking, observability and protection in more detail.
06 · Turn the registry into a governance point, not a bottleneck
Apply governance at the scope of the Harbor model you chose.
Section 4 chose the delivery scope. Section 5 established how Harbor fits approved enterprise standards and tools. This section completes the design by making ownership explicit. Governance does not require every registry to be a shared Supervisor Service, nor does it require replacing established identity, PKI, network, storage or operations services.
| Deployment model | Service owner | Consumer boundary |
|---|---|---|
| Harbor in a VKS cluster | The workload or cluster team owns lifecycle, recovery and integrations using approved enterprise standards and tools. | Use when the registry is intentionally local or isolated. The team accepts the operational responsibility. |
| Harbor as a Supervisor Service | The platform team owns the supported shared service, its prerequisites and its operations. | Application teams consume governed projects, roles and automation identities. They do not administer the shared infrastructure. |
| Regional Harbor through VCF Automation | The VCF platform team owns the regional platform service and its lifecycle. | Define whether it serves only platform content or also any approved tenant content, including retention and access responsibilities. |
Platform and security ownership
- Integrate the selected model with approved identity, certificate, network, storage, monitoring, backup and security controls.
- Define the service boundary, privileged access model, baseline retention, quota, scanning and audit policies.
- Operate availability, capacity, patching, recovery and escalation at the agreed service level.
Application team ownership
- Use the approved project or repository boundary, roles and robot accounts for CI/CD.
- Build, tag, promote and remove application content responsibly within the agreed policy.
- Own release decisions and the business impact of retained images, while following the platform's vulnerability response process.
A sensible shared registry baseline is one Harbor project per team or application boundary, least privilege roles, separate robot accounts for automation and quotas to prevent a noisy neighbour. For a local or independently operated Harbor, apply the same principles at the appropriate organisational boundary. Scanning is valuable only when a named owner makes the policy decision that follows the scan.
07 · OpenShift translation
For OpenShift readers, Harbor is closest to Red Hat Quay.
OpenShift has an integrated image registry for cluster local needs. Red Hat Quay is the closer comparison for a shared enterprise registry. It provides registry governance, security and multiple cluster patterns beyond the basic integrated registry.
| VKS and VCF | OpenShift | Useful translation |
|---|---|---|
| Harbor | Red Hat Quay | Enterprise container registry |
| Harbor project and RBAC | Quay organisation and repository permissions | Team separation and controlled access |
| Harbor replication, curated mirror or proxy cache | Quay geo replication or mirroring | Locality, resilience and disconnected image availability |
| Harbor Supervisor Service | Quay deployed through Quay Operator | Both are centrally delivered registry patterns, but the lifecycle mechanisms are not equivalent. |
The important distinction is simple. Harbor approximately maps to Quay as a product role. A Supervisor Service does not equal an OpenShift Operator. An Operator is a Kubernetes automation pattern. A Supervisor Service is the VCF delivery and governance model for a platform capability, and it can package an Operator.
08 · Practical example
Follow one image from build to production.
Imagine an Inventory API team that builds a new application image for VKS. The team does not start by asking for a new registry. It uses the shared Harbor service that the platform team already operates, with a dedicated project, least privilege access and robot accounts for the pipeline.
Build and publish
The CI pipeline builds the image, tags it with a release version and pushes it into the team's Harbor project. Harbor records the artifact, applies the project quota and makes the image visible to the people and automation identities that have access.
Scan and promote
The image is scanned before it is promoted for production use. If the scan result breaks policy, the release waits for an owner decision. If it passes, the approved tag becomes the one that the VKS workload is allowed to pull.
This is the daily operating value of Harbor. It gives the application team a clean release path while the platform team keeps control of identity, TLS trust, storage, monitoring, backup, retention and recovery. The architecture challenge is different. It asks where the registry boundaries should sit when several teams, stronger controls and a disconnected DR site enter the design.
09 · Knowledge check
Check the design thinking, not just the terminology.
1. Which statement is most accurate?
2. What should be completed before publishing Harbor as a production Supervisor Service?
3. Which Regional Harbor statement is safest for VCF 9.1?
4. Which comparison is technically sound?
5. When is a separate Harbor instance justified?
10 · Architecture challenge
Design the image supply chain for a regulated VKS platform.
Now move from one image workflow to a full platform design. Three application teams need to build and deploy images to VKS. The platform must avoid public registry dependency in production, support a disconnected DR site and stay operable for a small platform team.
Scenario
A financial services organisation is standardising Harbor for these consumers.
Strict release control, sensitive credentials, high audit expectations and tighter vulnerability response.
Large image layers, scheduled model builds and a need to run when internet access is restricted.
Standard web workloads with normal CI/CD promotion and moderate retention needs.
Required release content must be locally available when the primary site or internet path is unavailable.
- Choose the Harbor deployment model that fits the consumers. Consider local Harbor, Harbor as a Supervisor Service, Regional Harbor or another centrally operated Harbor pattern.
- Define the project, RBAC, robot account and quota pattern for each team.
- State how DNS, TLS, CA trust, ingress exposure, storage, monitoring and backup will use approved enterprise standards and tools.
- Decide how approved image content reaches the disconnected DR site. Use controlled replication or a curated mirror for required release images. Use proxy cache only where cached content and upstream dependency behaviour are acceptable.
- Define the retention, scanning, restore test and ownership rules that make the service credible.
Harbor projects isolate teams inside a registry. A separate Harbor instance is justified only when availability, recovery, latency, data residency or compliance requires a stronger boundary.
Reveal one reasonable design
Use a centrally operated Harbor pattern for application content, with separate projects and quotas per team. If the selected model is a Supervisor Service, include Contour as its documented ingress component. Otherwise, use the organisation's approved exposure, DNS, PKI, storage, monitoring and backup standards.
- Project boundary
- Dedicated project with restricted maintainers, separate robot accounts for build and deploy, and stricter retention.
- Policy
- Require scanning, promotion control and audit review before production pull access.
- Project boundary
- Dedicated project with larger quota and lifecycle rules tuned for model image size.
- Policy
- Use controlled replication or a curated mirror for required images. Use proxy cache only when the design can tolerate upstream dependency and confirms the needed content is already cached.
- Project boundary
- Shared baseline project with least privilege developer, maintainer and robot account roles.
- Policy
- Use the shared retention, scanning and vulnerability response workflow unless the application needs a stronger boundary.
- Content movement
- Use controlled replication or a curated mirror for approved release content.
- Recovery
- Test both Harbor service recovery and the ability for VKS workloads to pull required images during DR.
The registry endpoint is only one part of the design. The stronger architecture is the combination of ownership, trust, content movement, restore testing and team boundaries.
11 · Key takeaways
Build a trusted software supply chain, not just a registry endpoint.
- Harbor is an OCI registry, but the enterprise value comes from project boundaries, access control, scanning workflow, auditability, retention and content movement.
- Separate application images, VKS Standard Package content and Supervisor Service artifacts. They may all use OCI distribution, but they do not always have the same consumer or owner.
- For Harbor as a Supervisor Service, design Contour exposure, DNS, TLS and CA trust, persistent storage, capacity, monitoring, backup and restore before onboarding consumers. Other Harbor models should meet equivalent requirements through their supported architecture and approved enterprise standards.
- Regional Harbor is the VCF Automation managed pattern for selected platform service content in VCF 9.1. Treat it as a platform-content decision, not an automatic replacement for every application image registry.
- Projects, RBAC, robot accounts and quotas give teams autonomy inside a governed registry. Create a separate Harbor instance only when availability, recovery, latency, data residency or compliance requires a stronger boundary.
- Use controlled replication or a curated mirror for required production and DR images. Use proxy cache only when the design can tolerate upstream dependency and the required content is already cached.
- Harbor is closest to Red Hat Quay in an OpenShift translation. Compare the registry product role separately from the lifecycle model, because Supervisor Services and Operators are not the same thing.