在 Kubernetes 集群中,使用 OCI 客户端访问 OCI Registry 时,通常需要为客户端配置 Registry 认证信息。这就需要将认证信息分发给工作负载编排器,从而增加了凭证泄露的风险。
OCI Connector 提供了一种通过其代理能力以 secretless
方式访问 Registry 的方案,使普通用户无需接触认证信息即可访问 Registry,从而最大限度保障凭证安全。
目前社区中有多种 OCI 客户端可用于访问 OCI Registry
。本文档将介绍如何在 Kubernetes 工作负载中利用 OCI Connector
的代理能力,并说明其整体配置逻辑。
如果您已有初步了解,可以直接参考更具体的案例:
使用 OCI Connector 代理能力主要涉及以下三个方面:
接下来,我们将详细说明每一项的具体含义。
示例: harbar.example.com/test/abc
→ c-harbor-connector.default.svc.local/test/abc访问代理所需的认证信息可以通过 docker/config.json
文件进行配置。
OCI ConnectorClass
提供了开箱即用的配置,可以通过 connector-csi 挂载。
有关 OCI ConnectorClass 的配置信息,请参见 OCI ConnectorClass Configuration。
由于 connector 提供的代理服务使用 HTTP 协议,客户端需要配置 insecure-registries
。不同客户端的配置方式不同:
dockerd
可通过 daemon.json
指定。OCI ConnectorClass 提供了针对 dockerd
的开箱即用配置,可通过 connector-csi 挂载。
buildkitd.yaml
可通过 buildkitd.toml
指定。OCI ConnectorClass 提供了针对 buildkitd
的开箱即用配置,可通过 connector-csi 挂载。
某些工具支持直接在命令行指定,此时可将对应参数固定在脚本中。
例如:
buildah
在命令行指定 --tls-verify=false
以支持不安全的 Registry。ko
在命令行指定 --insecure-registry
以支持不安全的 Registry。