Alauda DevOps Connectors Docs

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 Capability

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

→ c-harbor-connector.default.svc.local/test/abc

  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:

dockerd can specify this through daemon.json. The OCI ConnectorClass provides an out-of-the-box configuration for dockerd, which can be mounted through connector-csi.

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

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