This document provides an overview of Managed Harbor Service (MHS) in Google Distributed Cloud (GDC) air-gapped.
MHS is a fully managed container registry based on the open-source Harbor project. Integrating MHS into your GDC environment provides a secure, scalable way to manage the lifecycle of your container artifacts in isolated environments without manual maintenance.
This overview introduces the foundational concepts required to work with MHS in GDC air-gapped, including the relationship between GDC projects and Harbor instance projects. It also details the administrative boundaries between infrastructure-level Identity and Access Management (IAM) roles and registry-level Role-based access control (RBAC), as well as core features such as automated garbage collection and service performance limits.
This document is for developers in platform administrator or application operator groups that use and administer MHS in GDC. For more information, see Audiences for GDC air-gapped documentation.
How Managed Harbor Service in GDC works
Operational planes
GDC MHS operates on two distinct functional layers of network architecture. Each layer enables specific operations:
- Management-plane layer: lets you create and delete Harbor registry instances.
- Data-plane layer: lets you push and pull container images in your Harbor instance.
Differences between GDC projects and Harbor instance projects
Managed Harbor Service involves two distinct project types. Understanding the interaction between these entities ensures you manage resources and access controls at the appropriate layer:
GDC project: The organizational unit for infrastructure management. Use this to manage the Harbor registry instance along with other GDC resources like VMs and clusters.
- Limits: A GDC project can contain only one Harbor instance. However, that single instance can be shared across multiple GDC projects to provide a centralized registry for your environment.
- Access: Requires GDC project-level IAM roles for instance creation, management, and administrative tasks.
Harbor instance project: A logical grouping for artifact management that exists within a Harbor instance. Use this to organize container images and repository-level access.
- Limits: A Harbor instance supports multiple Harbor projects. These can be allocated to individual teams or users to enable multi-tenancy within a shared registry.
- Access: Requires registry-specific RBAC roles to manage repositories, perform administrative tasks, and control artifact access within the project.
Features
Harbor is a Cloud Native Computing Foundation (CNCF) graduated open source project that provides a built-in cloud container registry solution for Kubernetes and Docker. With managed service integration, you can deploy a Harbor instance to store and manage artifacts on GDC. MHS offers the following features:
- Harbor instances are automatically provisioned and managed by GDC.
- Harbor is integrated with GDC's IAM for authentication and observability systems.
- Harbor instances can be upgraded to the newer stable version.
- Harbor is enhanced to meet GDC's compliance and quality requirements.
- A Harbor instance is a zonal resource; it's deployed in one zone, but it's accessible from any zones within the GDC deployment universe.
Identity and Access Management (IAM)
RBAC for Managed Harbor Service is applied at a both a GDC project-level, and a Harbor registry project-level. Users with the appropriate IAM roles can access and manage a Harbor instance within a GDC project, and users with the appropriate Harbor registry project roles can manage artifacts and perform administrative tasks within a Harbor project.
GDC-project IAM roles
GDC assigns project-level permissions using GDC-IAM roles. Find the required roles in your MHS procedural document, and ask your Organization IAM Admin to grant you access.
To perform Infrastructure Operator (IO) operations, check the GDC MHS service manuals to find the IAM roles required for your tasks.
Harbor registry project roles
A Harbor project uses its own set of RBAC mechanisms, which differ from GDC IAM roles.
To manage Harbor registry project repos and artifacts, you must have the correct Harbor role assigned at the Harbor project level. For a list of Harbor roles, refer to the Harbor document for managing user access: https://goharbor.io/docs/2.8.0/administration/managing-users/.
Performance
Google has tested and verified MHS to support the limits specified in System limits.
The actual performance limits might be higher.
Garbage collection
When you use MHS to add and delete images from the registry, unused data can build up over time. To avoid straining storage resources, MHS automatically performs garbage collection every 12 hours. You don't have to configure garbage collection manually.
What's next
To enable and use MHS, review the following documents:
- Create Harbor registry instances.
- Create Harbor instance projects.
- Manage Harbor registry instances.