Argo CD Config Management Plugins（CMP）完整指南：从 Sidecar 安装、发现规则到迁移与调试-酒店常州论坛

Argo CD Config Management Plugins（CMP）完整指南：从 Sidecar 安装、发现规则到迁移与调试

【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd

Argo CD 的原生配置管理工具是 Helm、Jsonnet 与 Kustomize，当需要接入其他工具或原生支持无法满足特定需求时，就需要引入 Config Management Plugin（CMP）。本文以 docs/operator-manual/config-management-plugins.md 为核心，系统讲解如何创建、安装、配置和使用 CMP：你将掌握 Sidecar 插件的完整安装流程、发现（Discovery）规则、环境变量与参数传递机制、从旧版argocd-cmConfigMap 插件的迁移步骤，以及常见问题的调试手段，并结合仓库源码（cmpserver/plugin/plugin.go、cmpserver/plugin/config.go、examples/plugins/helm）理解其底层实现原理。

说明：本文对应文档原位于docs/user-guide/config-management-plugins.md，现已迁移至 docs/operator-manual/config-management-plugins.md。

CMP 的工作原理与信任边界

Argo CD 的repo-server组件负责根据 Helm、OCI 或 Git 仓库中的源文件构建 Kubernetes 清单。当配置管理插件被正确配置后，repo-server 可以将构建清单的任务委托给插件执行。CMP 的运行方式是在argocd-repo-serverPod 中注入一个Sidecar 容器，该容器以argocd-cmp-server（一个轻量级 gRPC 服务）作为入口，Argo CD 通过 Unix Socket 与该服务通信，从而调用插件的init、generate、discover等命令。

[!WARNING] 插件在 Argo CD 系统中被赋予一定程度的信任，因此必须安全地实现插件。Argo CD 管理员只应从可信来源安装插件，并应审计插件以权衡其特定的风险与收益。

从源码结构看，CMP 的 gRPC 服务暴露了GenerateManifest、MatchRepository、GetParametersAnnouncement、CheckPluginConfiguration四个核心 RPC（见 cmpserver/plugin/plugin.go），分别对应清单生成、仓库匹配（发现）、参数通告与插件配置校验，整个服务器通过 Unix Socket 监听，实现在 cmpserver/server.go。

安装一个配置管理插件（Sidecar 方式）

安装一个插件需要三步：编写插件配置文件 → 将配置文件放入 Sidecar → 将插件注册为 repo-server 的 Sidecar 容器。

第一步：编写插件配置文件

插件通过一个ConfigManagementPlugin 清单进行配置，该清单存放在插件容器内部。下面是一个覆盖全部核心字段的完整示例：

apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: # 插件名称在给定的 Argo CD 实例内必须唯一。 name: my-plugin spec: # 插件版本。可选。如果指定了版本，Application 的 spec.source.plugin.name 字段 # 必须为 <插件名>-<插件版本>。 version: v1.0 # init 命令在每次清单生成开始时于 Application 源目录中运行。init 命令可以输出任何内容。 # 非零退出码将导致清单生成失败。 init: # init 总是在 generate 之前立即执行，但其输出不会被视为清单。 # 这是下载 chart 依赖等操作的理想位置。 command: [sh] args: [-c, 'echo "Initializing..."'] # generate 命令在每次生成清单时于 Application 源目录中运行。 # 标准输出必须 ONLY 是 YAML 或 JSON 格式的有效 Kubernetes 对象。 # 非零退出码将导致清单生成失败。 # 如需输出日志消息，请写入 stderr，它将始终被显示。 # 错误输出会发送到 UI，因此避免打印敏感信息（如密钥）。 generate: command: [sh, -c] args: - | echo "{\"kind\": \"ConfigMap\", \"apiVersion\": \"v1\", \"metadata\": { \"name\": \"$ARGOCD_APP_NAME\", \"namespace\": \"$ARGOCD_APP_NAMESPACE\", \"annotations\": {\"Foo\": \"$ARGOCD_ENV_FOO\", \"KubeVersion\": \"$KUBE_VERSION\", \"KubeApiVersion\": \"$KUBE_API_VERSIONS\",\"Bar\": \"baz\"}}}" # discovery 配置作用于仓库。如果每一个配置的 discovery 工具都匹配， # 则该插件可用于为该仓库的 Application 生成清单。 # 如果省略 discovery 配置，则插件不会匹配任何 Application， # 但可以通过在 app spec 中显式指定插件名来调用。 # fileName、find.glob、find.command 三者只能指定其一；若指定多个，仅第一个（按此顺序）会被评估。 discover: # fileName 是一个 glob 模式（https://pkg.go.dev/path/filepath#Glob），应用于 Application 的源目录。 # 如果有匹配，则该插件可用于该 Application。 fileName: "./subdir/s*.yaml" find: # glob 与 fileName 作用相同，但支持双星号（嵌套目录）glob 模式。 glob: "**/Chart.yaml" # find 命令在仓库根目录运行。要匹配成功，必须以状态码 0 退出 # 并且向标准输出产生非空输出。 command: [sh, -c, find . -name env.yaml] # parameters 配置描述 UI 应为 Application 显示哪些参数。 # 实际在 Application 清单中设置参数（位于 spec.source.plugin.parameters）由用户负责。 # 这些通告仅用于 App Details 页面的 "Parameters" 标签页。 parameters: # 静态参数通告会发送给该插件处理的所有 Application 的 UI。 # 这里的 string、array、map 值可视为"默认值"。 # 插件作者需要确保当用户未显式设置不同值时，这些默认值真实反映插件的行为。 static: - name: string-param title: Description of the string param tooltip: Tooltip shown when the user hovers the # 若设置该字段，UI 会提示用户必须设置该值。 required: false # itemType 告诉 UI 如何展示参数的值（对于数组和 map 则是其元素）。默认为 "string"。 # 未来可能支持 "boolean" 或 "number" 等其他类型。 # 即使 itemType 不是 "string"，Application spec 中的参数值也会以字符串形式发送给插件， # 由插件负责进行适当的转换。 itemType: "" # collectionType 描述该参数接受的值类型（string、array 或 map）， # 允许 UI 展示匹配的表单。默认为 "string"。 # 非字符串类型必须显式设置此字段；它不会因为存在 array 或 map 字段而被自动推断。 collectionType: "" # 该字段将参数的默认值传达给 UI。设置此字段是可选的。 string: default-string-value # 上述除 "string" 之外的所有字段同样适用于 array 和 map 类型的参数通告。 - name: array-param # 该字段将参数的默认值传达给 UI。设置此字段是可选的。 array: [default, items] collectionType: array - name: map-param # 该字段将参数的默认值传达给 UI。设置此字段是可选的。 map: some: value collectionType: map # 动态参数通告是针对该插件处理的某个具体 Application 的通告。 # 例如，Helm chart 的 values.yaml 文件中的值可以作为参数通告发送。 dynamic: # 命令在 Application 的源目录中运行。 # 标准输出必须是符合静态参数通告列表 schema 的 JSON。 command: [echo, '[{"name": "example-param", "string": "default-string-value"}]'] # 若设置为 true，插件将接收保留原始文件模式的仓库文件。 # 这很危险，因为仓库中可能存在可执行文件。仅在信任 CMP 插件作者时才设为 true。 preserveFileMode: false # 若设置为 true，插件可以在 generate 期间从 reposerver 获取 git 凭据。 # 插件作者应确保这些凭据在执行期间得到适当保护。 provideGitCreds: false

[!NOTE] 尽管 ConfigManagementPlugin 看起来像一个 Kubernetes 对象，但它并不是真正的自定义资源，只是遵循了 Kubernetes 风格的 spec 约定。

几个关键约束需要牢记：

generate命令必须在 stdout 打印一串有效的 Kubernetes YAML 或 JSON 对象流，init与generate命令都在 Application 源目录内执行。从源码看，生成的输出会经过kube.SplitYAMLToString解析为清单列表，任何非 K8s 对象内容都会导致生成失败（见 cmpserver/plugin/plugin.go）。
discover.fileName作为 glob 模式判断仓库是否被插件支持。如果未提供discover.fileName，则会执行discover.find.command来判断：命令需要以非错误退出码退出并且在标准输出产生输出，才表示该源类型被支持。

discover: find: command: [sh, -c, find . -name env.yaml]

从源码的matchRepository实现可以确认三种发现方式的评估顺序：spec.Discover.FileName→spec.Discover.Find.Glob（使用支持**的第三方库zglob实现）→spec.Discover.Find.Command，三者都未配置时返回"未启用发现"（见 cmpserver/plugin/plugin.go）。

第二步：将插件配置文件放入 Sidecar

Argo CD 期望插件配置文件位于 Sidecar 的/home/argocd/cmp-server/config/plugin.yaml（配置文件名plugin.yaml定义于 common/common.go）。

如果为 Sidecar 使用自定义镜像，可以直接将该文件打入镜像：

WORKDIR /home/argocd/cmp-server/config/ COPY plugin.yaml ./

如果使用官方镜像，或更愿意将插件配置维护在 ConfigMap 中，则可以将插件配置嵌套在 ConfigMap 的plugin.yamlkey 下并挂载到 Sidecar：

apiVersion: v1 kind: ConfigMap metadata: name: my-plugin-config data: plugin.yaml: | apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: name: my-plugin spec: version: v1.0 init: command: [sh, -c, 'echo "Initializing..."'] generate: command: [sh, -c, 'echo "{\"kind\": \"ConfigMap\", \"apiVersion\": \"v1\", \"metadata\": { \"name\": \"$ARGOCD_APP_NAME\", \"namespace\": \"$ARGOCD_APP_NAMESPACE\", \"annotations\": {\"Foo\": \"$ARGOCD_ENV_FOO\", \"KubeVersion\": \"$KUBE_VERSION\", \"KubeApiVersion\": \"$KUBE_API_VERSIONS\",\"Bar\": \"baz\"}}}"'] discover: fileName: "./subdir/s*.yaml"

第三步：注册插件 Sidecar

要安装插件，需要 patchargocd-repo-server，将插件容器作为 Sidecar 运行，并以argocd-cmp-server作为其入口。可以使用现成镜像或自定义构建的插件镜像作为 Sidecar 镜像：

containers: - name: my-plugin command: [/var/run/argocd/argocd-cmp-server] # 入口应为 Argo CD 轻量级 CMP server 即 argocd-cmp-server image: ubuntu # 可以是现成镜像或自定义构建镜像 securityContext: runAsNonRoot: true runAsUser: 999 volumeMounts: - mountPath: /var/run/argocd name: var-files - mountPath: /home/argocd/cmp-server/plugins name: plugins # 如果选择将配置文件打入 Sidecar 镜像，请移除这个 volumeMount。 - mountPath: /home/argocd/cmp-server/config/plugin.yaml subPath: plugin.yaml name: my-plugin-config # 从 v2.4 开始，不要挂载与 repo-server 容器相同的 tmp 卷。 # 文件系统隔离有助于缓解路径遍历攻击。 - mountPath: /tmp name: cmp-tmp volumes: - configMap: name: my-plugin-config name: my-plugin-config - emptyDir: {} name: cmp-tmp

[!IMPORTANT]请务必核对以下三项：
确保使用/var/run/argocd/argocd-cmp-server作为入口。argocd-cmp-server是一个轻量级 gRPC 服务，允许 Argo CD 与插件交互。
确保 Sidecar 容器以用户 999 运行。
确保插件配置文件存在于/home/argocd/cmp-server/config/plugin.yaml，它既可以通过 ConfigMap 卷映射，也可以打入镜像。

仓库中的 examples/plugins/helm/argocd-repo-server-deployment-patch.yaml 提供了一个完整的真实部署示例：通过 initContainer 下载 helm/jq/yq 工具到共享卷，插件容器以argocd-cmp-server为入口并挂载plugin.yaml与脚本，同时使用独立的emptyDir作为临时卷。从源码看，Sidecar 的 socket 文件命名规则为：指定了spec.version时是<插件名>-<版本>.sock，否则是<插件名>.sock（见 cmpserver/plugin/config.go），这与文档中"插件名称必须为<metadata.name>-<spec.version>"的约定一一对应。

在插件中使用环境变量

插件命令可以访问以下环境变量：

Sidecar 的系统环境变量。
标准构建环境变量，详见 docs/user-guide/build-environment.md（例如ARGOCD_APP_NAME、ARGOCD_APP_NAMESPACE、ARGOCD_APP_REVISION、KUBE_VERSION、KUBE_API_VERSIONS等，上文的 generate 示例即引用了这些变量）。
Application spec 中的变量（对系统变量和构建变量的引用会在变量值中进行插值）：

apiVersion: argoproj.io/v1alpha1 kind: Application spec: source: plugin: env: - name: FOO value: bar - name: REV value: test-$ARGOCD_APP_REVISION

在到达init.command、generate.command和discover.find.command命令之前，Argo CD 会为所有用户提供的环境变量（上述第 3 项）添加ARGOCD_ENV_前缀，以防止用户直接设置可能敏感的环境变量。从源码environ函数可以看出，这些变量最终会被拼接到插件命令的cmd.Env中执行（见 cmpserver/plugin/plugin.go）。

Application spec 中的参数：

apiVersion: argoproj.io/v1alpha1 kind: Application spec: source: plugin: parameters: - name: values-files array: [values-dev.yaml] - name: helm-parameters map: image.tag: v1.2.3

参数会以 JSON 形式放入ARGOCD_APP_PARAMETERS环境变量。上面的示例会产生如下 JSON：

[{"name": "values-files", "array": ["values-dev.yaml"]}, {"name": "helm-parameters", "map": {"image.tag": "v1.2.3"}}]

[!NOTE] 参数通告（即使指定了默认值）不会通过ARGOCD_APP_PARAMETERS发送给插件。只有 Application spec 中显式设置的参数才会发送给插件。插件需要自行应用与 UI 通告相同的默认值。

同一组参数也可以作为独立的环境变量使用，命名约定如下：

- name: some-string-param string: some-string-value # PARAM_SOME_STRING_PARAM=some-string-value - name: some-array-param value: [item1, item2] # PARAM_SOME_ARRAY_PARAM_0=item1 # PARAM_SOME_ARRAY_PARAM_1=item2 - name: some-map-param map: image.tag: v1.2.3 # PARAM_SOME_MAP_PARAM_IMAGE_TAG=v1.2.3

[!WARNING]净化/转义用户输入
作为 Argo CD 清单生成系统的一部分，配置管理插件被赋予一定程度的信任。请务必在插件中转义用户输入，防止恶意输入引发意外行为。

仓库示例 examples/plugins/helm/generate.sh 展示了如何消费这些变量：用jq从ARGOCD_APP_PARAMETERS中解析出values-files数组生成--values=参数、解析helm-parametersmap 生成--set=参数，最终组装成helm template命令。

在 Application 中使用配置管理插件

在plugin节中可以将name字段留空，让插件根据其发现规则自动匹配 Application。如果填写了名称，必须确保其为<metadata.name>-<spec.version>（当 ConfigManagementPlugin spec 中声明了 version 时）或<metadata.name>（未声明 version 时）。当显式指定名称时，只有该插件在其发现模式/命令匹配提供的 Application 仓库时才会被使用。

apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd spec: project: default source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook plugin: env: - name: FOO value: bar

如果不需要设置任何环境变量，可以设置空的 plugin 节：

plugin: {}

[!IMPORTANT] 如果 CMP 命令运行时间过长，命令会被终止，UI 会显示错误。CMP server 会遵循argocd-cmd-params-cm中server.repo.server.timeout.seconds和controller.repo.server.timeout.seconds项设置的超时时间（默认 60 秒），必要时请调大。
每条 CMP 命令还会依据 CMP Sidecar 上设置的ARGOCD_EXEC_TIMEOUT独立超时，默认 90 秒。因此如果将 repo server 超时调大到 90 秒以上，务必在 Sidecar 上设置ARGOCD_EXEC_TIMEOUT。
如果 CMP 命令未能在ARGOCD_EXEC_TIMEOUT内优雅退出，它将在额外一段ARGOCD_EXEC_FATAL_TIMEOUT时间后被强制杀死。

[!NOTE] 每个 Application 同一时间只能配置一个配置管理插件。如果正在将原本通过argocd-cmConfigMap 配置的插件转换为 Sidecar，请确保将插件名更新为<metadata.name>-<spec.version>（若 ConfigManagementPlugin spec 中声明了 version）或直接使用<metadata.name>。也可以完全移除名称，让自动发现来识别插件。

[!NOTE] 如果 CMP 渲染出空白清单，且prune设置为true，Argo CD 会自动删除资源。CMP 插件作者应确保错误体现在退出码中。常见的kustomize build . | cat这类写法会因管道而吞掉错误，请考虑使用set -o pipefail，让任何管道命令在失败时都能传递错误。

调试一个 CMP

如果你正在积极开发一个 Sidecar 安装的 CMP，请记住以下几点：

如果是从 ConfigMap 挂载 plugin.yaml，需要重启 repo-server Pod，插件才会拾取变更。
如果已将 plugin.yaml 打入镜像，则需要构建、推送并强制重新拉取该镜像。若使用:latest，Pod 总是会拉取新镜像；若使用其他静态标签，请在 CMP 的 Sidecar 容器上设置imagePullPolicy: Always。
CMP 错误会被 repo-server 缓存在 Redis 中。重启 repo-server Pod 无法清除缓存。开发 CMP 时始终执行 "Hard Refresh"，以获得最新输出。
通过查看 Pod 确认 Sidecar 已正常启动，两个容器都在运行：kubectl get pod -l app.kubernetes.io/component=repo-server -n argocd
将日志消息写入 stderr，并在 Sidecar 上设置--loglevel=info标志。这将打印所有写入 stderr 的内容，即使在命令成功执行时也会打印。

其他常见错误

| 错误信息 | 原因 | | -- | -- | |no matches for kind "ConfigManagementPlugin" in version "argoproj.io/v1alpha1"|ConfigManagementPluginCRD 已在 Argo CD 2.4 中弃用并在 2.8 中移除。此错误意味着你试图将插件配置直接作为 Kubernetes CRD 放入集群。请参考上文"编写插件配置文件"一节，了解如何编写插件配置文件并将其正确放入 Sidecar。 |

插件 tar 流排除（Plugin tar stream exclusions）

为提高清单生成速度，可以排除某些文件和文件夹，使其不发送给插件。如果.git目录非必需，建议将其排除。

使用**跨目录边界匹配。例如.git/**会排除.git/内的所有内容。

[!NOTE] 在 v3.6 之前不支持**。如果现有排除规则中包含/（例如.git/*），升级后请复查它们，因为匹配行为可能与之前不同。

可以通过以下三种方式之一设置：

repo server 上的--plugin-tar-exclude参数（可重复多次）。
使用argocd-cmd-params-cm时的reposerver.plugin.tar.exclusionskey。
直接在 repo server 上设置ARGOCD_REPO_SERVER_PLUGIN_TAR_EXCLUSIONS环境变量。

对于方式 2 和 3，可以用分号分隔多个 glob 规则。

使用 argocd.argoproj.io/manifest-generate-paths 注解生成清单

为了优化应用清单生成过程，可以启用argocd.argoproj.io/manifest-generate-paths注解。启用后，只有该注解指定的资源会被传给 CMP server 用于生成应用清单，而不是发送整个仓库。这对于**单体仓库（monorepo）**尤其有用。

同样有三种设置方式：

repo server 上的--plugin-use-manifest-generate-paths参数。
使用argocd-cmd-params-cm时的reposerver.plugin.use.manifest.generate.pathskey。
直接在 repo server 上设置ARGOCD_REPO_SERVER_PLUGIN_USE_MANIFEST_GENERATE_PATHS环境变量为true。

从 argocd-cm 插件迁移

通过修改argocd-cmConfigMap 安装插件的方式自 v2.4 起已弃用，自v2.8起被完全移除。CMP 插件通过向argocd-repo-server添加 Sidecar 以及该 Sidecar 中位于/home/argocd/cmp-server/config/plugin.yaml的配置来工作。一个 argocd-cm 插件可以通过以下步骤轻松转换。

将 ConfigMap 条目转换为配置文件

首先将插件的配置复制到它自己的 YAML 文件中。以下面的 ConfigMap 条目为例：

data: configManagementPlugins: | - name: pluginName init: # 可选，初始化应用源目录的命令 command: ["sample command"] args: ["sample args"] generate: # 生成 YAML 或 JSON 格式 Kubernetes 对象的命令 command: ["sample command"] args: ["sample args"] lockRepo: true # 默认 false。见下文。

pluginName条目会被转换为如下配置文件：

apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: name: pluginName spec: init: # 可选，初始化应用源目录的命令 command: ["sample command"] args: ["sample args"] generate: # 生成 YAML 或 JSON 格式 Kubernetes 对象的命令 command: ["sample command"] args: ["sample args"]

[!NOTE]lockRepokey 对 Sidecar 插件没有意义，因为 Sidecar 插件在生成清单时不会共享同一个源仓库目录。

接下来，需要决定如何将此 YAML 添加到 Sidecar：可以将其直接打入镜像，也可以从 ConfigMap 挂载。

如果使用 ConfigMap，示例将如下所示：

apiVersion: v1 kind: ConfigMap metadata: name: pluginName namespace: argocd data: pluginName.yaml: | apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: name: pluginName spec: init: # 可选，初始化应用源目录的命令 command: ["sample command"] args: ["sample args"] generate: # 生成 YAML 或 JSON 格式 Kubernetes 对象的命令 command: ["sample command"] args: ["sample args"]

然后将此 ConfigMap 挂载到插件 Sidecar 中。

为插件编写发现规则

Sidecar 插件既可以使用发现规则，也可以使用插件名称来匹配 Application 与插件。如果省略发现规则，则必须在 app spec 中显式指定插件名，否则该插件不会匹配任何应用。

如果希望使用发现（而不是插件名）来匹配应用，请按照上文"编写插件配置文件"一节的规则编写适用于你的插件的规则，并将其添加到配置文件中。

若要使用名称而非发现，请将 Application 清单中的名称更新为<metadata.name>-<spec.version>（若 ConfigManagementPlugin spec 中声明了 version）或直接使用<metadata.name>。例如：

apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook spec: source: plugin: name: pluginName # 如需自动发现请删除此项（如果 name 是唯一值则设置 `plugin: {}`），或使用正确的 sidecar 插件名

确保插件能访问它需要的工具

使用 argocd-cm 配置的插件运行在 Argo CD 镜像上，因此默认可以访问该镜像上安装的所有工具（可查看仓库根目录的 Dockerfile 了解基础镜像与已安装工具）。

现在可以选择使用现成镜像（如 ubuntu、busybox 或 alpine/k8s），也可以设计包含插件所需工具的自定义基础镜像。出于安全考虑，应避免使用比插件实际需要安装更多二进制的镜像。

测试插件

按照上文"安装一个配置管理插件"的步骤将插件安装为 Sidecar 后，在将所有Application 迁移到 Sidecar 插件之前，先在少数 Application 上测试。

测试通过后，从argocd-cmConfigMap 中移除插件条目。

附加设置

保留仓库文件模式（Preserve repository files mode）

默认情况下，配置管理插件接收的源仓库文件会重置文件模式，这是出于安全考虑。如果希望保留原始文件模式，可以在插件 spec 中设置preserveFileMode为true：

[!WARNING] 请确保你信任所使用的插件。如果将preserveFileMode设为true，插件可能会收到带有可执行权限的文件，这可能带来安全风险。

apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: name: pluginName spec: init: command: ["sample command"] args: ["sample args"] generate: command: ["sample command"] args: ["sample args"] preserveFileMode: true

从源码看，该开关会直接传递给仓库文件流接收逻辑cmp.ReceiveRepoStream（见 cmpserver/plugin/plugin.go），决定解包时是否保留原文件权限位。

提供 Git 凭据（Provide Git Credentials）

默认情况下，配置管理插件需要自行为其在清单生成期间可能需要访问的其他Git 仓库提供凭据。而 repo-server 在其 git 凭据存储中已经持有这些凭据。当允许凭据共享时，repo-server 用于克隆仓库内容的 git 凭据会在配置管理插件执行的整个生命周期内共享，通过 git 的ASKPASS机制，让配置管理 Sidecar 容器调用 repo-server 以获取已初始化的 git 凭据。

利用ASKPASS意味着凭据不是主动共享的，而是仅在某个操作确实需要时才提供。

ASKPASS需要在配置管理插件与 repo-server 之间共享一个socket。为缓解路径遍历攻击，建议使用专用卷共享该 socket，并将其挂载到 repo-server 和 Sidecar 中。若要更改 socket 路径，必须为两个容器都设置ARGOCD_ASK_PASS_SOCK环境变量。

要允许插件访问 repo-server 的 git 凭据，可以在插件 spec 中设置provideGitCreds为true：

[!WARNING] 请确保你信任所使用的插件。如果将provideGitCreds设为true，插件将收到用于克隆源 Git 仓库的凭据。

apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: name: pluginName spec: init: command: ["sample command"] args: ["sample args"] generate: command: ["sample command"] args: ["sample args"] provideGitCreds: true

provideGitCreds状态会通过CheckPluginConfigurationRPC 暴露给 repo-server（见 cmpserver/plugin/plugin.go），由 repo-server 决定是否在生成阶段为插件启用凭据转发。

参考资源

官方文档主体：docs/operator-manual/config-management-plugins.md
完整可运行的 Helm 示例插件：examples/plugins/helm/plugin.yaml、examples/plugins/helm/argocd-repo-server-deployment-patch.yaml、examples/plugins/helm/generate.sh、examples/plugins/helm/get-parameters.sh
CMP 服务端实现：cmpserver/server.go、cmpserver/plugin/plugin.go
插件配置解析与校验：cmpserver/plugin/config.go
常用路径与常量定义：common/common.go
标准构建环境变量说明：docs/user-guide/build-environment.md

【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析