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:
Using the OCI Connector proxy capability mainly involves the following three aspects:
Next, we will elaborate on the specific meaning of each item.
Example: harbar.example.com/test/abc:v1 → c-harbor-connector.default.svc.local/namespaces/oci-connector-ns/connectors/oci-connector-name/test/abc:v1
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.
For the configuration information of the OCI ConnectorClass, please refer to OCI ConnectorClass Configuration.
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.
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.
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.