Alauda DevOps Connectors Docs
  • English

    • Using the OCI Connector Proxy in K8S Workload

    In a Kubernetes cluster, when using the OCI client to access the OCI 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 OCI 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 OCI clients available in the community for accessing the OCI Registry. This document will introduce how to utilize the proxy capabilities of the OCI 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 OCI Connector Proxy CapabilityForward ProxyReverse ProxyMore

    Utilizing OCI Connector Proxy Capability

    The OCI 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

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

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

    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 OCI ConnectorClass Forward Proxy for default configurations provided by the ConnectorClass.

    Reverse Proxy

    Using the OCI 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: harbar.example.com/test/abc:v1 → c-harbor-connector.default.svc.local/namespaces/oci-connector-ns/connectors/oci-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 docker/config.json file.

    The OCI 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: "docker-config"

    For the configuration information of the OCI ConnectorClass, please refer to OCI 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.yaml can specify this through buildkitd.toml. The OCI 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