Making Harbor production-ready: Important issues for deployment

Harbor is an open-source container registry that secures artifacts with insurance policies and role-based entry management, making certain pictures are scanned for vulnerabilities and signed as trusted. To be taught extra about Harbor and the best way to deploy it on a Digital Machine (VM) and in Kubernetes (K8s), discuss with elements 1 and a pair of of the collection.

Whereas deploying Harbor is easy, making it production-ready requires cautious consideration of a number of key elements. This weblog outlines crucial components to make sure your Harbor occasion is strong, safe, and scalable for manufacturing environments.

For this weblog, we are going to give attention to Harbor deployed on Kubernetes through Helm as our base and supply solutions for this particular deployment.

1. Excessive Availability (HA) and scalability

For a manufacturing setting, single factors of failure are unacceptable, particularly for a picture registry that can act as a central repository for storing and pulling pictures and artifacts for growth and manufacturing functions. Thus, implementing excessive availability for Harbor is essential and includes a number of key issues:

• Deploy with an Ingress: Configure a Kubernetes Service of kind Ingress controller (e.g. Traefik) in entrance of your Harbor situations to distribute incoming site visitors effectively and supply a unified entry level together with cert-manager for certificates administration. You may specify this in your values.yaml file beneath:

expose:
  kind: ingress
  tls:
    enabled: true
    certSource: secret 
  ingress:
    hosts:
      core: harbor.yourdomain.com
    annotations:
      # Specify your ingress class
      kubernetes.io/ingress.class: traefik
      # Reference your ClusterIssuer (e.g., self-signed or inner CA)
      cert-manager.io/cluster-issuer: "harbor-cluster-issuer"

To find your values.yaml file, discuss with the earlier weblog.

• Make the most of a number of Harbor situations: Enhance the duplicate depend for crucial Harbor parts (e.g., core, jobservice, portal, registry, trivy) in your values.yaml to make sure redundancy.

core:
  replicas: 3
jobservice:
  replicas: 3
portal:
  replicas: 3
registry:
  replicas: 3
trivy:
  replicas: 3

# Whereas not strictly for the HA of the registry itself, contemplate growing exporter replicas for strong monitoring availability
exporter:
  replicas: 3

# Optionally, if utilizing Ingress, contemplate growing the Nginx replicas for bettering Ingress availability
nginx:
  replicas: 3

Configure shared storage: For persistent information, configure Kubernetes StorageClasses and PersistentVolumes to make use of shared storage options like vSAN or a distributed file system. Specify these in your values.yaml beneath:

persistence:
  enabled: true
  resourcePolicy: "keep"
  persistentVolumeClaim:
    registry:
      #If left empty, the kubernetes cluster default storage class can be used
      storageClass: "your-storage-class"
     jobservice:
       storageClass: "your-storage-class"
     database:
       storageClass: "your-storage-class"
    redis:
      storageClass: "your-storage-class"
    trivy:
      storageClass: "your-storage-class"

• Allow database HA (PostgreSQL): Whereas Harbor comes with a built-in PostgreSQL database, it’s not really helpful for manufacturing use because it: 

1. Lack of excessive availability (HA): The default inner PostgreSQL setup throughout the Harbor Helm chart is often a single occasion. This creates a single level of failure. If that database pod goes down, your complete Harbor occasion can be unavailable.

2. Restricted scalability: An embedded database is just not designed for impartial scaling. In case your Harbor utilization grows, you may hit database efficiency bottlenecks which can be troublesome to deal with with out disrupting Harbor itself.

3. Complicated lifecycle administration: Managing backups, point-in-time restoration, patching, and upgrades for a stateful database immediately inside an software’s Helm chart may be considerably extra advanced and error-prone than with devoted database options.

Thus, it’s endorsed to deploy a extremely obtainable PostgreSQL cluster inside Kubernetes (e.g., utilizing a Helm chart for Patroni or CloudNativePG) or leverage a managed database service outdoors the cluster. Configure Harbor to hook up with this HA database by updating the values.yaml:

database:
  kind: "external"
  exterior:
    host: "192.168.0.1"
    port: "5432"
    username: "user"
    password: "password"
    coreDatabase: "registry"
    # If utilizing an current secret, the important thing have to be "password"
    existingSecret: ""
    # "disable" - No SSL
    # "require" - At all times SSL (skip verification)
    # "verify-ca" - At all times SSL (confirm that the certificates introduced by the
    # server was signed by a trusted CA)
    # "verify-full" - At all times SSL (confirm that the certification introduced by the
    # server was signed by a trusted CA and the server host title matches the one
    # within the certificates)
    sslmode: "verify-full"

Implement Redis HA: Deploy a extremely obtainable Redis cluster in Kubernetes (e.g., utilizing a Helm chart for Redis Sentinel or Redis Cluster) or make the most of a managed Redis service. Configure Harbor to hook up with this HA Redis occasion by updating redis.kind and connection particulars in values.yaml.

redis:
  kind: exterior
  exterior:
    addr: "192.168.0.2:6397"
    sentinelMasterSet: ""
    tlsOptions:
      allow: true
    username: ""
    password: ""

2. Safety greatest practices

Safety is paramount for any manufacturing system, particularly a container registry.

​​Allow TLS/SSL: At all times allow TLS/SSL for all Harbor parts.

expose:
  tls:
    enabled: true
    certSource: auto # change to handbook if utilizing cert-manager
    auto:
      commonName: ""
internalTLS:
  enabled: true
  strong_ssl_ciphers: true
  certSource: "auto"
  core:
    secretName: ""
  jobService:
    secretName: ""
  registry:
    secretName: ""
  portal:
    secretName: ""
  trivy:
    secretName: ""

Configure authentication and authorization: Leverage Harbor’s supported Authentication and Authorization mechanisms for managing entry to Harbor sources. After Harbor deployment, combine Harbor with enterprise id suppliers like LDAP or OIDC by following the Harbor configuration guides: Configure LDAP/Energetic Listing Authentication or Configure OIDC Supplier Authentication.

Implement vulnerability scanning: Guarantee vulnerability scanning is enabled in values.yaml. Harbor makes use of Trivy by default. Confirm its activation and configuration throughout the Helm chart.

trivy:
 enabled: true

Activate content material belief: Harbor helps a number of content material belief mechanisms to make sure the integrity of your artifacts. For contemporary OCI artifact signing, Cosign and Notation are really helpful. Implement deployment safety on the venture degree throughout the Harbor UI or through the Harbor API to permit solely verified pictures to be deployed. This ensures that solely trusted and cryptographically signed pictures may be deployed.

• Keep common updates: Frequently replace your Harbor Helm chart and underlying Kubernetes parts to learn from the most recent safety patches and bug fixes. Use helm improve for this objective.

• Use robotic accounts for automation: Use robotic accounts (service accounts) in automation similar to CI/CD pipelines to keep away from utilizing consumer credentials. This ensures the robotic account with the least required privileges is used to carry out the precise activity it has been created for, making certain restricted scope.
• Positive grained audit log: In Harbor v2.13.0, Harbor helps the re-direction of particular occasions within the audit log.  For instance, an “authentication failure”  occasion may be configured within the audit log and forwarded to a third celebration syslog endpoint.

3. Storage issues

Environment friendly and dependable storage is crucial for Harbor’s efficiency and stability.

• Select acceptable storage kind: Outline Kubernetes StorageClasses that align along with your underlying infrastructure (e.g., nfs-client, aws-ebs, azure-disk, gcp-pd). Specify these settings in your values.yaml: 

persistence:
  enabled: true
  resourcePolicy: "keep"
  imageChartStorage:
    #Specify storage kind: "filesystem", "azure", "gcs", "s3", "swift", "oss"
    kind: ""
    #Configure particular storage kind part based mostly on the chosen possibility

• Estimate storage sizing: Fastidiously calculate your storage wants based mostly on the anticipated quantity and measurement of container pictures, in addition to your outlined retention insurance policies. Configure the scale on your PersistentVolumeClaims in values.yaml.

• Implement strong backup and restoration: Set up a complete backup technique for all Harbor information. For Kubernetes-native backups, think about using instruments like Velero to again up PersistentVolumes and Kubernetes sources. For object storage, leverage the cloud supplier’s backup mechanisms or exterior backup options. Frequently check your restoration procedures.

• Configure and run rubbish assortment: Arrange and routinely execute Harbor’s rubbish assortment. This may be configured by way of the Harbor UI by defining a schedule for automated runs to take away unused blobs and effectively reclaim space for storing.

4. Monitoring and alerting

Proactive monitoring and alerting are important for figuring out and addressing points earlier than they affect customers.
Accumulate Complete Metrics: Deploy Prometheus and configure it to scrape metrics from Harbor parts. The Harbor Helm chart exposes Prometheus-compatible endpoints within the values.yaml file. Visualize these metrics utilizing Grafana.

metrics:
  enabled: true
  core:
    path: /metrics
    port: 8001
  registry:
    path: /metrics
    port: 8001
  jobservice:
    path: /metrics
    port: 8001
  exporter:
    path: /metrics
    port: 8001
  serviceMonitor:
    enabled: true
    # This label ensures the prometheus operator picks up these screens
    additionalLabels:
      launch: kube-prometheus-stack

# Instance Service Monitor objects:

# Harbor Core (API and Auth Efficiency)
apiVersion: monitoring.coreos.com/v1
type: ServiceMonitor
metadata:
  title: harbor-core
  labels:
    app: harbor
    launch: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: harbor
      element: core
  endpoints:
  - port: metrics # Defaults to 8001
    path: /metrics
    interval: 30s

# Harbor Exporter (Enterprise Metrics)
apiVersion: monitoring.coreos.com/v1
type: ServiceMonitor
metadata:
  title: harbor-exporter
  labels:
    app: harbor
    launch: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: harbor
      element: exporter
  endpoints:
  - port: metrics
    path: /metrics
    interval: 60s # Scraped much less steadily as these are high-level stats

• Centralized logging: Implement a centralized logging resolution inside Kubernetes, such because the ELK stack (Elasticsearch, Logstash, Kibana) or Grafana with Fluentd/Fluent Bit. 

• Configure crucial alerts: Arrange alerting guidelines in Prometheus (Alertmanager) or Grafana for crucial occasions, similar to element failures, excessive useful resource utilization (CPU/reminiscence limits), storage nearing capability, failed vulnerability scans, or unauthorized entry makes an attempt. Outline these thresholds based mostly in your manufacturing necessities.

5. Community configuration

Correct community configuration ensures clean communication between Harbor parts and exterior shoppers.

• Configure ingress or load balancer and DNS decision: As already talked about, deploy a Kubernetes Ingress controller or Load Balancer to reveal Harbor externally. Guarantee correct DNS data are configured to level to your Load Balancer’s IP tackle.

• Set Up proxy settings (if relevant): If Harbor parts have to entry exterior sources by way of a company proxy, configure proxy settings inside values.yaml. It’s essential to notice that the proxy.parts discipline explicitly defines which Harbor parts (e.g., core, jobservice, trivy) will make the most of these proxy settings for his or her exterior communications.

proxy:
  httpProxy:
  httpsProxy:
  noProxy: 127.0.0.1,localhost,.native,.inner
  parts:
    - core
    - jobservice
    - trivy

• Allocate ample bandwidth: Guarantee your Kubernetes cluster’s underlying community infrastructure and nodes have ample bandwidth to deal with peak picture pushes and pulls. Monitor community I/O on nodes operating Harbor pods.

Conclusion

By diligently addressing these issues, you may rework your primary Harbor deployment into a sturdy, safe, and extremely obtainable production-ready container registry. This strategy ensures that Harbor serves as a cornerstone of your cloud-native infrastructure, able to supporting demanding growth and manufacturing workflows. From implementing Excessive Availability and stringent safety measures to optimizing storage and establishing proactive monitoring, every step contributes to a resilient and environment friendly artifact administration system. 

Proceed studying the Harbor Weblog Collection on cncf.io:

Weblog 1 – Harbor: Enterprise-grade container registry for contemporary personal cloud

Weblog 2 – Deploying Harbor on Kubernetes utilizing Helm