Alauda DevOps Connectors Docs

Using the Harbor Connector Proxy in K8S Workload

In a Kubernetes cluster, when using container registry clients to access the Harbor Registry, it is often necessary to configure the Registry authentication information for the client. This requires distributing the authentication information to the workload orchestrators, thereby increasing the risk of credential leakage.

The Harbor Connector provides a secretless way to access the Registry through its proxy capability, allowing ordinary users to access the Registry without having contact with authentication information, thus maximizing credential security.

Currently, there are various container registry clients available in the community for accessing the Harbor Registry. This document will introduce how to utilize the proxy capabilities of the Harbor Connector in Kubernetes workloads and explain its general configuration logic.

If you already have a preliminary understanding, you can directly refer to more specific cases:

TOC

Utilizing Harbor Connector Proxy CapabilityForward ProxyReverse ProxyMore

Utilizing Harbor Connector Proxy Capability

The Harbor Connector supports two proxy modes:

  • Forward Proxy - Recommended for most cases. Less intrusive to client configurations and easier to use.
  • Reverse Proxy - Requires modifying the target image address and additional client configuration.

Forward Proxy

Using Forward Proxy involves the following aspects:

  • Setting proxy environment variables for the client
  • Configuring the client to support insecure registries (if required)

Mount the built-in configurations through the Connectors CSI Driver:

volumes:
- name: proxyconfig
  csi:
    readOnly: true
    driver: connectors-csi
    volumeAttributes:
      connector.name: "harbor"

Most container registry clients support reading proxy settings from environment variables (http_proxy, https_proxy, no_proxy). You can configure them in two ways:

# Option 1: Set proxy variables individually
export http_proxy=$(cat /{mount-path}/http.proxy)
export https_proxy=$(cat /{mount-path}/https.proxy)
export HTTP_PROXY=$http_proxy
export HTTPS_PROXY=$https_proxy
export no_proxy=localhost,127.0.0.1
export NO_PROXY=$no_proxy

# Option 2: Source the environment file
source /{mount-path}/.env

Note: Some clients require specifying proxy settings in their configuration files.

Since the forward proxy intercepts and re-signs TLS traffic (MITM), clients must be configured to trust the proxy's certificate or allow insecure connections. Refer to your CLI documentation for details, or see the Harbor ConnectorClass Forward Proxy for default configurations provided by the ConnectorClass.

Reverse Proxy

Using the Harbor Connector proxy capability mainly involves the following three aspects:

  • Modifying the target image address to the proxied image repository address
  • Configuring the authentication information required to access the proxy
  • Configuring the client CLI to support pushing to insecure registries

Next, we will elaborate on the specific meaning of each item.

  1. Modifying the target image address to the proxied image repository address

Example: harbor.example.com/test/abc:v1 → c-harbor-connector.default.svc.local/namespaces/harbor-connector-ns/connectors/harbor-connector-name/test/abc:v1

  1. Configuring the authentication information required to access the proxy

The authentication information required to access the proxy can be configured through the config.json file.

The Harbor ConnectorClass provides an out-of-the-box configuration that can be mounted through connector-csi.

volumes:
- name: docker-config
  csi:
    readOnly: true
    driver: connectors-csi
    volumeAttributes:
      connector.name: "harbor"
      configuration.names: "config"

For the configuration information of the Harbor ConnectorClass, please refer to Harbor ConnectorClass Configuration.

  1. Configuring the client CLI to support pushing to insecure registries

Since the proxy service provided by the connector uses HTTP protocol, it is necessary to configure insecure-registries on the client. Different clients have different configuration methods:

buildkitd can specify this through buildkitd.toml. The Harbor ConnectorClass provides an out-of-the-box configuration for buildkitd, which can be mounted through connector-csi.

- name: buildkitd-config
  csi:
    readOnly: true
    driver: connectors-csi
    volumeAttributes:
      connector.name: "harbor"
      configuration.names: "buildkitd"

Certain tools may support specifying directly in the command line, in which case the corresponding parameters can be fixed in the script.

For example:

  • buildah specifies --tls-verify=false in the command line to support insecure registry.
  • ko specifies --insecure-registry in the command line to support insecure registry.

More