尧图网站建设 
Argo CD 使用 Kubernetes Impersonation 解耦 Application Sync 与控制平面权限【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd本技术指南以 decouple-application-sync-user-using-impersonation.md 设计提案为骨架结合 argo-cd 仓库当前源码系统讲解 Argo CD 如何通过 Kubernetes 用户伪装Impersonation能力将 Application 同步Sync时使用的权限与应用控制平面运行权限解耦实现最小权限的多租户部署。读完本文你将掌握AppProject中destinationServiceAccounts配置项的完整语义与匹配规则、argocd-cm中功能开关的真实配置键以及面向单集群/多集群的四种实战同步场景配置方法。背景为什么需要解耦同步权限与控制平面权限在 Argo CD 中Application 的同步操作默认复用 Argo CD 控制平面Application Controller持有的集群凭据。这意味着在多租户场景下Argo CD 控制平面的权限必须与权限需求最高的那个租户对齐。例如一个 Argo CD 实例管理 10 个 Application其中只有 1 个需要 admin 权限那么为了让这 1 个应用能正常同步整个控制平面就必须拥有 admin 权限参见提案 Background。Argo CD 虽然提供了基于AppProject的多租户模型来限制每个 Application 能做什么但这只是限制层面的约束——一旦控制平面被攻破攻击者依然会获得集群级管理员权限攻击面很大。该提案的目标是使用 Impersonation 以另一个用户的身份执行 Application 同步而集群配置Cluster Config中提供的 Service Account 仅用于控制平面自身的操作。什么是 Kubernetes ImpersonationImpersonation 是 Kubernetes 内建特性kubectlCLI 客户端内置支持。通过伪装请求头一个用户可以在认证后以另一个用户的身份发起请求。典型场景管理员临时伪装成某个用户调试授权策略、验证某请求是否被拒绝。伪装请求的流程是先以请求者身份完成认证再切换到被伪装者的用户信息。kubectl --as user-to-impersonate ... kubectl --as user-to-impersonate --as-group group-to-impersonate ...Impersonation 要求发起方具备对应 RBAC 权限能够对users、groups或serviceaccounts资源执行impersonate动词后文示例 4 会给出具体 RBAC 配置。同时Kubernetes 审计日志会同时记录真实用户与被伪装用户因此可以追踪谁以谁的权限执行了命令。提案动机与设计目标在多团队 / 多租户环境中应用团队通常只被授予某个命名空间的自助管理权限。此前Argo CD 管理员必须在AppProject中复制每个团队的 RBAC 配置既重复劳动又容易造成安全态势不一致。本提案的价值用 Kubernetes 原生 RBAC 管理集群权限替代AppProject中复杂的白名单/黑名单配置来限制应用解耦应用同步所需权限与控制平面运行所需权限实现最小权限原则改善 Argo CD 整体安全态势支撑一个团队一个命名空间甚至一个应用一个命名空间的多租户场景。设计假设命名空间已预置一个或多个ServiceAccount用来定义每个AppProject的权限许多用户更倾向于用 Kubernetes RBAC 而非 Argo CD 特有构造来管控资源访问每个租户通常被授予特定命名空间 相应 ServiceAccount / Role / ClusterRole / RoleBinding租户创建的Application管理的是命名空间内资源一个AppProject可映射到单个或多个相关租户并配置相应需要管理的目标destinations。目标GoalsApplication 只能伪装与其目标命名空间处于同一命名空间的 ServiceAccount若 ServiceAccount 在其他命名空间可使用namespace:service_account_name格式显式指定。每个应用同步使用的 ServiceAccount 由AppProject关联的目标决定若启用 Impersonation 但AppProject未指定 ServiceAccount 名称则使用 Application 目标命名空间的defaultServiceAccountAppProject已有的访问限制白名单/黑名单等必须保持原有行为不变切换到 ServiceAccount 方案后原有安全限制依然生效该功能仅支持系统级开关一旦启用/禁用对所有 Argo CDApplication生效。非目标提案未列出明确的 Non-Goals。核心 API 设计AppProject.spec.destinationServiceAccountsArgo CD 管理员可以在AppProjectCR 中为单个或一组 destination 指定 ServiceAccount 名称。destination 由目标集群 命名空间组合唯一标识。当 Application 同步时控制器根据其目标集群与命名空间的组合在AppProject中选出配置的defaultServiceAccount并以该身份执行同步操作。提案在AppProject.spec中引入了新元素destinationServiceAccounts仅用于表达伪装配置。如果 Impersonation 已启用但AppProject中未提供具体 ServiceAccount则使用目标命名空间中的defaultServiceAccount。apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: description: Example Project # Allow manifests to deploy from any Git repos sourceRepos: - * destinations: - * destinationServiceAccounts: - server: https://kubernetes.default.svc namespace: guestbook defaultServiceAccount: guestbook-deployer - server: https://kubernetes.default.svc namespace: guestbook-dev defaultServiceAccount: guestbook-dev-deployer - server: https://kubernetes.default.svc namespace: guestbook-stage defaultServiceAccount: guestbook-stage-deployer - server: * namespace: * defaultServiceAccount: default # catch all service account to be used when all other matches fail.DestinationServiceAccount 结构参数类型必填/可选说明serverstringRequired目标集群 Kubernetes 控制平面 API 的 URL支持 glob 模式匹配namespacestringRequiredApplication 资源的目标命名空间支持 glob 模式匹配defaultServiceAccountstringRequired执行 Application 同步操作时所要伪装的 ServiceAccount注意只支持目标集群的 server URL不支持目标集群名称。源码中的结构体与校验该设计已在仓库中落地为真实类型。结构体定义位于 types.go// ApplicationDestinationServiceAccount holds information about the service account to be impersonated for the application sync operation. type ApplicationDestinationServiceAccount struct { // Server specifies the URL of the target clusters Kubernetes control plane API. Server string json:server protobuf:bytes,1,opt,nameserver // Namespace specifies the target namespace for the applications resources. Namespace string json:namespace,omitempty protobuf:bytes,2,opt,namenamespace // DefaultServiceAccount to be used for impersonation during the sync operation DefaultServiceAccount string json:defaultServiceAccount protobuf:bytes,3,opt,namedefaultServiceAccount }AppProjectSpec中的字段定义位于 types.go// DestinationServiceAccounts holds information about the service accounts to be impersonated for the application sync operation for each destination. DestinationServiceAccounts []ApplicationDestinationServiceAccount json:destinationServiceAccounts,omitempty protobuf:bytes,14,namedestinationServiceAccountsAppProject.ValidateProject()app_project_types.go会强制以下约束任何一条不满足都会拒绝该 AppProjectserver与namespace字段中不允许出现!字符避免与destinations中的否定语义混淆defaultServiceAccount不能为空去空格后且不允许包含字符集!*[]{}\/常量serviceAccountDisallowedCharSet见 app_project_types.goserver、namespace必须能编译为合法的 glob 模式使用github.com/gobwas/glob每一组server/namespace组合必须唯一重复会被拒绝。从校验规则可以推断设计者刻意限制了defaultServiceAccount中不能出现*、[]、{}、/、\等字符避免服务账号名中混入 glob 通配或路径分隔符带来的歧义而!的禁用则是为了防止与destinations字段的否定运算符语义冲突。启用 Impersonation 功能三种开关形式1. argocd-cm ConfigMap 配置推荐在argocd-cmConfigMap 中设置配置键application.sync.impersonation.enabled: true默认值为false需显式开启。对应的源码位于 settings.go// impersonationEnabledKey is the key to configure whether the application sync decoupling through impersonation feature is enabled impersonationEnabledKey application.sync.impersonation.enabled ... defaultImpersonationEnabledFlag false // application sync with impersonation enforcement is enabled by default (applies only when defaultImpersonationEnabledFlag is enabled) defaultImpersonationEnforcedFlag trueSettingsManager.IsImpersonationEnabled()settings.go读取该键cm.Data[application.sync.impersonation.enabled] true即为启用。关于提案与实现的差异说明提案正文的 Implementation Details 中提到了applicationcontroller.enable.impersonation、环境变量ARGOCD_APPLICATION_CONTROLLER_ENABLE_IMPERSONATION与--enable-impersonation命令行参数但当前仓库实际落地的配置键是application.sync.impersonation.enabled提案示例中的 patch 命令使用的也是这个键。以当前仓库源码为准。2. 强制执行开关源码新增特性除启用开关外仓库还实现了第二个配置键application.sync.impersonation.enforced见 settings.go 与 IsImpersonationEnforced默认值为true仅在启用开关开启时才有意义当 Impersonation 已启用、但未能在destinationServiceAccounts中找到匹配项时若enforcedtrue同步操作直接失败OperationError提示 no matching service account found for destination server ... and namespace ...若enforcedfalse记录 info 日志后回退使用控制器的 ServiceAccount 继续执行。这一强制/回退二态设计是源码在提案基础上的细化让管理员可以灵活选择宁可失败也不越权还是允许回退到控制平面凭据。核心匹配逻辑DeriveServiceAccountToImpersonate伪装目标的推导集中在util/settings/impersonation.go的DeriveServiceAccountToImpersonate函数impersonation.go其行为完全对应提案中的特殊场景约定确定 ServiceAccount 的命名空间作用域优先取Application.Spec.Destination.Namespace如果为空则退回到 Application 自身的命名空间application.Namespace顺序遍历project.Spec.DestinationServiceAccounts用 glob 分别匹配server与namespaceglob.MatchWithError两者都命中即为候选采用第一个有效匹配对应提案Multiple matches of destinations约定组装完整服务账号名若defaultServiceAccount含:形如mynamespace:guestbook-deployer则直接拼接为system:serviceaccount:mynamespace:guestbook-deployer否则拼接为system:serviceaccount:serviceAccountNamespace:name若无任何匹配返回空字符串交由上层根据enforced配置决定失败或回退。同步链路中的实际应用sync 与 server-side diff同步Sync路径Application 控制器在执行同步时会读取argocd-cm的开关若启用则推导 ServiceAccount并同时在rawConfig与restConfig上设置rest.ImpersonationConfigsync.goif impersonationEnabled { serviceAccountToImpersonate, err : settings.DeriveServiceAccountToImpersonate(project, app, destCluster) ... if serviceAccountToImpersonate { // No matching service account found - check enforcement impersonationEnforced, enforcedErr : m.settingsMgr.IsImpersonationEnforced() ... if impersonationEnforced { state.Phase common.OperationError state.Message fmt.Sprintf(no matching service account found for destination server %s and namespace %s, destCluster.Server, app.Spec.Destination.Namespace) return } // Non-enforced mode: log info and continue with controller SA logEntry.Infof(no matching service account found for impersonation ... falling back to controller service account, ...) } else { logEntry logEntry.WithFields(log.Fields{impersonationEnabled: true, serviceAccount: serviceAccountToImpersonate}) // set the impersonation headers. rawConfig.Impersonate rest.ImpersonationConfig{ UserName: serviceAccountToImpersonate, } restConfig.Impersonate rest.ImpersonationConfig{ UserName: serviceAccountToImpersonate, } } }这两个 config 随后被传入sync.NewSyncContext(...)sync.go从而保证整个同步周期内所有 kubectl 调用都以伪装身份执行。这也印证了提案中Fix Application Controller sync.go 将 Impersonate 配置从 AppProject CR 注入 SyncContext的实现要点。比较 / Server-Side Diff 路径比较diff阶段同样会应用伪装配置以保证比较看到的权限与同步使用的权限一致。applyDiffImpersonationConfigsync.go镜像了同步路径的行为启用时推导 ServiceAccount 并设置config.Impersonate rest.ImpersonationConfig{UserName: ...}未找到匹配时同样依据enforced决定报错或回退并记录 debug 日志 server-side diff: no matching service account found ... falling back to controller service account。此外控制器在管理集群连接配置时也会统一应用伪装appcontroller.go 的applyImpersonationConfig。实战示例以下四个示例完整对应提案的 Detailed examples覆盖本集群全命名空间通配、本集群指定命名空间、远端集群使用默认 argocd-manager、远端集群使用自定义服务账号四类典型场景。公共前置安装 Argo CD以下示例部署在argocd命名空间并开启 Impersonation 功能。启用 Impersonation 功能公共步骤kubectl patch cm argocd-cm -n argocd --type json --patch [{ op: add, path: /data/application.sync.impersonation.enabled, value: true }]示例 1AppProject 级对所有命名空间指定同步服务账号场景服务账号名generic-deployer用于应用同步因为命名空间guestbook匹配 glob 模式*。安装 ArgoCD 到argocd命名空间kubectl apply --server-side -f https://raw.githubusercontent.com/argoproj/argo-cd/master/manifests/install.yaml -n argocd创建命名空间与服务账号kubectl create namespace guestbook kubectl create serviceaccount guestbook-deployer创建 Role 与 RoleBinding为guestbook-deployer配置在guestbook命名空间创建Service和Deployment的 RBAC 权限kubectl create role guestbook-deployer-role --verb get,list,update,delete --resource pods,deployment,service kubectl create rolebinding guestbook-deployer-rb --serviceaccount guestbook-deployer --role guestbook-deployer-role创建 Application 与 AppProjectapiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd spec: project: my-project source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc namespace: guestbook --- apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: description: Example Project # Allow manifests to deploy from any Git repos sourceRepos: - * destinations: - namespace: * server: https://kubernetes.default.svc destinationServiceAccounts: - namespace: * server: https://kubernetes.default.svc defaultServiceAccount: generic-deployer此场景中namespace: *是第一个也是唯一有效匹配因此generic-deployer会被用于同步。示例 2AppProject 级对指定命名空间指定同步服务账号场景服务账号名guestbook-deployer将用于应用同步因为命名空间guestbook精确匹配目标命名空间guestbook。安装与启用步骤同示例 1随后kubectl create namespace guestbook kubectl create serviceaccount guestbook-deployerkubectl create role guestbook-deployer-role --verb get,list,update,delete --resource pods,deployment,service kubectl create rolebinding guestbook-deployer-rb --serviceaccount guestbook-deployer --role guestbook-deployer-role此场景下guestbook-deployer精确匹配命名空间guestbookapiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd spec: project: my-project source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc namespace: guestbook --- apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: description: Example Project # Allow manifests to deploy from any Git repos sourceRepos: - * destinations: - namespace: guestbook server: https://kubernetes.default.svc - namespace: guestbook-ui server: https://kubernetes.default.svc destinationServiceAccounts: - namespace: guestbook server: https://kubernetes.default.svc defaultServiceAccount: guestbook-deployer - namespace: guestbook-ui server: https://kubernetes.default.svc defaultServiceAccount: guestbook-ui-deployer示例 3远端集群 默认 argocd-managercluster-admin注意本示例依赖通过 Argo CD CLI 添加远端集群时创建的默认 ServiceAccountargocd-manager具备cluster-admin权限。argocd cluster add remote-cluster --name remote-cluster说明上述命令会在kube-system命名空间创建名为argocd-manager的 ServiceAccount、名为argocd-manager-role的 ClusterRole完整集群管理员权限以及名为argocd-manager-role-binding的 ClusterRoleBinding将argocd-manager-role绑定到服务账号remote-cluster。在远端集群中创建命名空间与服务账号kubectl ctx remote-cluster kubectl create namespace guestbook kubectl create serviceaccount guestbook-deployer在远端集群中配置 RBACkubectl ctx remote-cluster kubectl create role guestbook-deployer-role --verb get,list,update,delete --resource pods,deployment,service kubectl create rolebinding guestbook-deployer-rb --serviceaccount guestbook-deployer --role guestbook-deployer-role创建 Application 与 AppProjectapiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd spec: project: my-project source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc namespace: guestbook --- apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: description: Example Project # Allow manifests to deploy from any Git repos sourceRepos: - * destinations: - namespace: guestbook server: https://kubernetes.default.svc destinationServiceAccounts: - namespace: guestbook server: https://kubernetes.default.svc defaultServiceAccount: guestbook-deployer示例 4远端集群 自定义服务账号非 cluster-admin注意本示例为同步操作使用目标集群与命名空间中创建的非默认服务账号guestbook适用于远端集群由不同管理员管理、无法提供 cluster-admin 级服务账号的场景。在远端集群创建具备伪装权限的服务账号argocd-adminkubectl ctx remote-cluster kubectl create serviceaccount argocd-admin kubectl create clusterrole argocd-admin-role --verbimpersonate --resourceusers,groups,serviceaccounts kubectl create clusterrole argocd-admin-role-access-review --verbcreate --resourceselfsubjectaccessreviews kubectl create clusterrolebinding argocd-admin-role-binding --serviceaccount argocd-admin --clusterrole argocd-admin-role kubectl create clusterrolebinding argocd-admin-access-review-role-binding --serviceaccount argocd-admin --clusterrole argocd-admin-role关键点argocd-admin需要具备impersonate动词权限针对users、groups、serviceaccounts以及创建selfsubjectaccessreviews的权限Kubernetes 在发起伪装请求时会先执行 SubjectAccessReview 检查。在远端集群创建目标命名空间与服务账号kubectl ctx remote-cluster kubectl create namespace guestbook kubectl create serviceaccount guestbook-deployer配置目标服务账号的 RBACkubectl create role guestbook-deployer-role --verb get,list,update,delete --resource pods,deployment,service kubectl create rolebinding guestbook-deployer-rb --serviceaccount guestbook-deployer --role guestbook-deployer-role此场景中guestbook-deployer因精确匹配命名空间guestbook而被使用apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd spec: project: my-project source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc namespace: guestbook --- apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: description: Example Project # Allow manifests to deploy from any Git repos sourceRepos: - * destinations: - namespace: guestbook server: https://kubernetes.default.svc - namespace: guestbook-ui server: https://kubernetes.default.svc destinationServiceAccounts: - namespace: guestbook server: https://kubernetes.default.svc defaultServiceAccount: guestbook-deployer - namespace: guestbook-ui server: https://kubernetes.default.svc defaultServiceAccount: guestbook-ui-deployer特殊场景与匹配规则在其它命名空间指定 ServiceAccount默认情况下ServiceAccount 会在 Application 的目标命名空间Application.Spec.Destination.Namespace中查找。如果 ServiceAccount 位于其它命名空间可用namespace:service_account_name格式显式指定... destinationServiceAccounts: - server: https://kubernetes.default.svc namespace: * defaultServiceAccount: mynamespace:guestbook-deployer ...多个 destination 同时匹配时若同一目标命中多个destinationServiceAccounts条目使用列表中第一个有效匹配。例如... destinationServiceAccounts: - server: https://kubernetes.default.svc namespace: guestbook-prod defaultServiceAccount: guestbook-prod-deployer - server: https://kubernetes.default.svc namespace: guestbook-* defaultServiceAccount: guestbook-generic-deployer - server: https://kubernetes.default.svc namespace: * defaultServiceAccount: generic-deployer ...Application 目标命名空间为myns只有 glob*命中使用generic-deployer目标命名空间为guestbook-dev或guestbook-stage*与guestbook-*都命中但guestbook-*排在更前因此使用guestbook-generic-deployer目标命名空间为guestbook-prod三个都命中但列表中第一个有效匹配是guestbook-prod-deployer故使用它。Git 仓库中资源横跨多个命名空间用于伪装的 ServiceAccount 是按 Application 级别确定的而不是按单个资源级别。Application.spec.destination.namespace的值会用于确定该 Application 内所有资源的同步服务账号——即使 Git 仓库中的某些清单硬编码了其它命名空间。Application 未设置 spec.destination.namespacespec.destination.namespace在Application中是可选字段。未指定时控制器使用Application 自身命名空间中的服务账号执行同步与DeriveServiceAccountToImpersonate中serviceAccountNamespace 时的回退逻辑一致见 impersonation.go用户也可显式指定带命名空间的服务账号。apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd spec: project: my-project source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc --- apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: description: Example Project # Allow manifests to deploy from any Git repos sourceRepos: - * destinations: - namespace: guestbook server: https://kubernetes.default.svc - namespace: guestbook-ui server: https://kubernetes.default.svc destinationServiceAccounts: - namespace: guestbook server: https://kubernetes.default.svc defaultServiceAccount: guestbook-deployer - namespace: guestbook-ui server: https://kubernetes.default.svc defaultServiceAccount: guestbook-ui-deployer上例中由于未指定spec.destination.namespace使用 Application 命名空间argocd作为服务账号作用域即system:serviceaccount:argocd:guestbook-deployer会被用于同步。若匹配的服务账号显式带命名空间如guestbook:guestbook-deployer则使用system:serviceaccount:guestbook:guestbook-deployer。安全考量、风险与缓解安全影响启用该特性后Argo CD 工作负载的同步操作以受限身份执行控制平面即使被攻破攻击者能够获得的权限也被限制在目标 ServiceAccount 的 RBAC 范围内显著缩小了爆炸半径。风险权限提升如果允许用户无限制地伪装会引入权限提升风险。缓解措施只有管理员能在AppProject级别配置用于同步的服务账号使用 Kubernetes RBAC 的resourceNames字段限制某个 ServiceAccount 可以伪装的具体对象而不是放任其伪装所有用户/组。例如可以在 ClusterRole 中为impersonate权限指定具体的resourceNames将可伪装范围收敛到特定服务账号。升级 / 降级策略该特性基于 feature flag 采用opt-in默认关闭方式实现新增的AppProject.Spec字段是可选的只有显式开启 feature flag 后才生效若在 CR 中使用了新字段但未开启 feature flag则在 CR 调和reconcile期间会显示警告消息升级到启用 Impersonation 的版本后未配置destinationServiceAccounts的现有 AppProject 行为保持不变回退到默认default服务账号或依据enforced配置处理。已知取舍Drawbacks使用该特性需要额外维护命名空间、ServiceAccount、相应 RBAC 策略并将 ServiceAccount 与AppProject配置一一对应存在一定的运维开销。备选方案与设计取舍备选方案完整暴露 ImpersonationConfig一种更激进的方案是向用户暴露ImpersonationConfig的全部选项用户名、UID、组apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd spec: description: Example Project # Allow manifests to deploy from any Git repos sourceRepos: - * destinations: - namespace: * server: https://kubernetes.default.svc namespace: guestbook impersonate: user: system:serviceaccount:dev_ns:admin uid: 1234 groups: - admin - view - edit该方案未被采纳以保持初始设计的最小化将来可根据需求与反馈再支持用户/组的伪装。设计决策要点源码与提案相互印证不扩展destinations字段该字段的语义是限制 Application 可用的目标且支持!否定运算符会复杂化服务账号匹配逻辑因此在AppProject.Spec下新增独立结构字段名选用defaultServiceAccount而非serviceAccount为将来在 Application 级别覆盖服务账号预留serviceAccount名称全局项目继承destinationServiceAccounts已纳入全局项目Global Projects可继承字段列表见 projects.md与destinations等字段一并支持从全局项目继承方便统一管理。未来增强提案规划的未来方向包括在 Application 级别支持覆盖服务账号届时将向AppProject.spec.destinationServiceAccounts[*]增加allowedServiceAccounts元素。延伸阅读提案全文decouple-application-sync-user-using-impersonation.mdAPI 结构体定义types.goAppProject 校验逻辑app_project_types.go服务账号推导算法impersonation.go功能开关与强制策略settings.go同步路径伪装实现sync.goServer-Side Diff 伪装实现sync.go控制器的伪装配置应用appcontroller.goAppProject 用户指南含全局项目继承字段说明projects.md【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Argo CD 使用 Kubernetes Impersonation 解耦 Application Sync 与控制平面权限
Argo CD 使用 Kubernetes Impersonation 解耦 Application Sync 与控制平面权限【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd本技术指南以 decouple-application-sync-user-using-impersonation.md 设计提案为骨架结合 argo-cd 仓库当前源码系统讲解 Argo CD 如何通过 Kubernetes 用户伪装Impersonation能力将 Application 同步Sync时使用的权限与应用控制平面运行权限解耦实现最小权限的多租户部署。读完本文你将掌握AppProject中destinationServiceAccounts配置项的完整语义与匹配规则、argocd-cm中功能开关的真实配置键以及面向单集群/多集群的四种实战同步场景配置方法。背景为什么需要解耦同步权限与控制平面权限在 Argo CD 中Application 的同步操作默认复用 Argo CD 控制平面Application Controller持有的集群凭据。这意味着在多租户场景下Argo CD 控制平面的权限必须与权限需求最高的那个租户对齐。例如一个 Argo CD 实例管理 10 个 Application其中只有 1 个需要 admin 权限那么为了让这 1 个应用能正常同步整个控制平面就必须拥有 admin 权限参见提案 Background。Argo CD 虽然提供了基于AppProject的多租户模型来限制每个 Application 能做什么但这只是限制层面的约束——一旦控制平面被攻破攻击者依然会获得集群级管理员权限攻击面很大。该提案的目标是使用 Impersonation 以另一个用户的身份执行 Application 同步而集群配置Cluster Config中提供的 Service Account 仅用于控制平面自身的操作。什么是 Kubernetes ImpersonationImpersonation 是 Kubernetes 内建特性kubectlCLI 客户端内置支持。通过伪装请求头一个用户可以在认证后以另一个用户的身份发起请求。典型场景管理员临时伪装成某个用户调试授权策略、验证某请求是否被拒绝。伪装请求的流程是先以请求者身份完成认证再切换到被伪装者的用户信息。kubectl --as user-to-impersonate ... kubectl --as user-to-impersonate --as-group group-to-impersonate ...Impersonation 要求发起方具备对应 RBAC 权限能够对users、groups或serviceaccounts资源执行impersonate动词后文示例 4 会给出具体 RBAC 配置。同时Kubernetes 审计日志会同时记录真实用户与被伪装用户因此可以追踪谁以谁的权限执行了命令。提案动机与设计目标在多团队 / 多租户环境中应用团队通常只被授予某个命名空间的自助管理权限。此前Argo CD 管理员必须在AppProject中复制每个团队的 RBAC 配置既重复劳动又容易造成安全态势不一致。本提案的价值用 Kubernetes 原生 RBAC 管理集群权限替代AppProject中复杂的白名单/黑名单配置来限制应用解耦应用同步所需权限与控制平面运行所需权限实现最小权限原则改善 Argo CD 整体安全态势支撑一个团队一个命名空间甚至一个应用一个命名空间的多租户场景。设计假设命名空间已预置一个或多个ServiceAccount用来定义每个AppProject的权限许多用户更倾向于用 Kubernetes RBAC 而非 Argo CD 特有构造来管控资源访问每个租户通常被授予特定命名空间 相应 ServiceAccount / Role / ClusterRole / RoleBinding租户创建的Application管理的是命名空间内资源一个AppProject可映射到单个或多个相关租户并配置相应需要管理的目标destinations。目标GoalsApplication 只能伪装与其目标命名空间处于同一命名空间的 ServiceAccount若 ServiceAccount 在其他命名空间可使用namespace:service_account_name格式显式指定。每个应用同步使用的 ServiceAccount 由AppProject关联的目标决定若启用 Impersonation 但AppProject未指定 ServiceAccount 名称则使用 Application 目标命名空间的defaultServiceAccountAppProject已有的访问限制白名单/黑名单等必须保持原有行为不变切换到 ServiceAccount 方案后原有安全限制依然生效该功能仅支持系统级开关一旦启用/禁用对所有 Argo CDApplication生效。非目标提案未列出明确的 Non-Goals。核心 API 设计AppProject.spec.destinationServiceAccountsArgo CD 管理员可以在AppProjectCR 中为单个或一组 destination 指定 ServiceAccount 名称。destination 由目标集群 命名空间组合唯一标识。当 Application 同步时控制器根据其目标集群与命名空间的组合在AppProject中选出配置的defaultServiceAccount并以该身份执行同步操作。提案在AppProject.spec中引入了新元素destinationServiceAccounts仅用于表达伪装配置。如果 Impersonation 已启用但AppProject中未提供具体 ServiceAccount则使用目标命名空间中的defaultServiceAccount。apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: description: Example Project # Allow manifests to deploy from any Git repos sourceRepos: - * destinations: - * destinationServiceAccounts: - server: https://kubernetes.default.svc namespace: guestbook defaultServiceAccount: guestbook-deployer - server: https://kubernetes.default.svc namespace: guestbook-dev defaultServiceAccount: guestbook-dev-deployer - server: https://kubernetes.default.svc namespace: guestbook-stage defaultServiceAccount: guestbook-stage-deployer - server: * namespace: * defaultServiceAccount: default # catch all service account to be used when all other matches fail.DestinationServiceAccount 结构参数类型必填/可选说明serverstringRequired目标集群 Kubernetes 控制平面 API 的 URL支持 glob 模式匹配namespacestringRequiredApplication 资源的目标命名空间支持 glob 模式匹配defaultServiceAccountstringRequired执行 Application 同步操作时所要伪装的 ServiceAccount注意只支持目标集群的 server URL不支持目标集群名称。源码中的结构体与校验该设计已在仓库中落地为真实类型。结构体定义位于 types.go// ApplicationDestinationServiceAccount holds information about the service account to be impersonated for the application sync operation. type ApplicationDestinationServiceAccount struct { // Server specifies the URL of the target clusters Kubernetes control plane API. Server string json:server protobuf:bytes,1,opt,nameserver // Namespace specifies the target namespace for the applications resources. Namespace string json:namespace,omitempty protobuf:bytes,2,opt,namenamespace // DefaultServiceAccount to be used for impersonation during the sync operation DefaultServiceAccount string json:defaultServiceAccount protobuf:bytes,3,opt,namedefaultServiceAccount }AppProjectSpec中的字段定义位于 types.go// DestinationServiceAccounts holds information about the service accounts to be impersonated for the application sync operation for each destination. DestinationServiceAccounts []ApplicationDestinationServiceAccount json:destinationServiceAccounts,omitempty protobuf:bytes,14,namedestinationServiceAccountsAppProject.ValidateProject()app_project_types.go会强制以下约束任何一条不满足都会拒绝该 AppProjectserver与namespace字段中不允许出现!字符避免与destinations中的否定语义混淆defaultServiceAccount不能为空去空格后且不允许包含字符集!*[]{}\/常量serviceAccountDisallowedCharSet见 app_project_types.goserver、namespace必须能编译为合法的 glob 模式使用github.com/gobwas/glob每一组server/namespace组合必须唯一重复会被拒绝。从校验规则可以推断设计者刻意限制了defaultServiceAccount中不能出现*、[]、{}、/、\等字符避免服务账号名中混入 glob 通配或路径分隔符带来的歧义而!的禁用则是为了防止与destinations字段的否定运算符语义冲突。启用 Impersonation 功能三种开关形式1. argocd-cm ConfigMap 配置推荐在argocd-cmConfigMap 中设置配置键application.sync.impersonation.enabled: true默认值为false需显式开启。对应的源码位于 settings.go// impersonationEnabledKey is the key to configure whether the application sync decoupling through impersonation feature is enabled impersonationEnabledKey application.sync.impersonation.enabled ... defaultImpersonationEnabledFlag false // application sync with impersonation enforcement is enabled by default (applies only when defaultImpersonationEnabledFlag is enabled) defaultImpersonationEnforcedFlag trueSettingsManager.IsImpersonationEnabled()settings.go读取该键cm.Data[application.sync.impersonation.enabled] true即为启用。关于提案与实现的差异说明提案正文的 Implementation Details 中提到了applicationcontroller.enable.impersonation、环境变量ARGOCD_APPLICATION_CONTROLLER_ENABLE_IMPERSONATION与--enable-impersonation命令行参数但当前仓库实际落地的配置键是application.sync.impersonation.enabled提案示例中的 patch 命令使用的也是这个键。以当前仓库源码为准。2. 强制执行开关源码新增特性除启用开关外仓库还实现了第二个配置键application.sync.impersonation.enforced见 settings.go 与 IsImpersonationEnforced默认值为true仅在启用开关开启时才有意义当 Impersonation 已启用、但未能在destinationServiceAccounts中找到匹配项时若enforcedtrue同步操作直接失败OperationError提示 no matching service account found for destination server ... and namespace ...若enforcedfalse记录 info 日志后回退使用控制器的 ServiceAccount 继续执行。这一强制/回退二态设计是源码在提案基础上的细化让管理员可以灵活选择宁可失败也不越权还是允许回退到控制平面凭据。核心匹配逻辑DeriveServiceAccountToImpersonate伪装目标的推导集中在util/settings/impersonation.go的DeriveServiceAccountToImpersonate函数impersonation.go其行为完全对应提案中的特殊场景约定确定 ServiceAccount 的命名空间作用域优先取Application.Spec.Destination.Namespace如果为空则退回到 Application 自身的命名空间application.Namespace顺序遍历project.Spec.DestinationServiceAccounts用 glob 分别匹配server与namespaceglob.MatchWithError两者都命中即为候选采用第一个有效匹配对应提案Multiple matches of destinations约定组装完整服务账号名若defaultServiceAccount含:形如mynamespace:guestbook-deployer则直接拼接为system:serviceaccount:mynamespace:guestbook-deployer否则拼接为system:serviceaccount:serviceAccountNamespace:name若无任何匹配返回空字符串交由上层根据enforced配置决定失败或回退。同步链路中的实际应用sync 与 server-side diff同步Sync路径Application 控制器在执行同步时会读取argocd-cm的开关若启用则推导 ServiceAccount并同时在rawConfig与restConfig上设置rest.ImpersonationConfigsync.goif impersonationEnabled { serviceAccountToImpersonate, err : settings.DeriveServiceAccountToImpersonate(project, app, destCluster) ... if serviceAccountToImpersonate { // No matching service account found - check enforcement impersonationEnforced, enforcedErr : m.settingsMgr.IsImpersonationEnforced() ... if impersonationEnforced { state.Phase common.OperationError state.Message fmt.Sprintf(no matching service account found for destination server %s and namespace %s, destCluster.Server, app.Spec.Destination.Namespace) return } // Non-enforced mode: log info and continue with controller SA logEntry.Infof(no matching service account found for impersonation ... falling back to controller service account, ...) } else { logEntry logEntry.WithFields(log.Fields{impersonationEnabled: true, serviceAccount: serviceAccountToImpersonate}) // set the impersonation headers. rawConfig.Impersonate rest.ImpersonationConfig{ UserName: serviceAccountToImpersonate, } restConfig.Impersonate rest.ImpersonationConfig{ UserName: serviceAccountToImpersonate, } } }这两个 config 随后被传入sync.NewSyncContext(...)sync.go从而保证整个同步周期内所有 kubectl 调用都以伪装身份执行。这也印证了提案中Fix Application Controller sync.go 将 Impersonate 配置从 AppProject CR 注入 SyncContext的实现要点。比较 / Server-Side Diff 路径比较diff阶段同样会应用伪装配置以保证比较看到的权限与同步使用的权限一致。applyDiffImpersonationConfigsync.go镜像了同步路径的行为启用时推导 ServiceAccount 并设置config.Impersonate rest.ImpersonationConfig{UserName: ...}未找到匹配时同样依据enforced决定报错或回退并记录 debug 日志 server-side diff: no matching service account found ... falling back to controller service account。此外控制器在管理集群连接配置时也会统一应用伪装appcontroller.go 的applyImpersonationConfig。实战示例以下四个示例完整对应提案的 Detailed examples覆盖本集群全命名空间通配、本集群指定命名空间、远端集群使用默认 argocd-manager、远端集群使用自定义服务账号四类典型场景。公共前置安装 Argo CD以下示例部署在argocd命名空间并开启 Impersonation 功能。启用 Impersonation 功能公共步骤kubectl patch cm argocd-cm -n argocd --type json --patch [{ op: add, path: /data/application.sync.impersonation.enabled, value: true }]示例 1AppProject 级对所有命名空间指定同步服务账号场景服务账号名generic-deployer用于应用同步因为命名空间guestbook匹配 glob 模式*。安装 ArgoCD 到argocd命名空间kubectl apply --server-side -f https://raw.githubusercontent.com/argoproj/argo-cd/master/manifests/install.yaml -n argocd创建命名空间与服务账号kubectl create namespace guestbook kubectl create serviceaccount guestbook-deployer创建 Role 与 RoleBinding为guestbook-deployer配置在guestbook命名空间创建Service和Deployment的 RBAC 权限kubectl create role guestbook-deployer-role --verb get,list,update,delete --resource pods,deployment,service kubectl create rolebinding guestbook-deployer-rb --serviceaccount guestbook-deployer --role guestbook-deployer-role创建 Application 与 AppProjectapiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd spec: project: my-project source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc namespace: guestbook --- apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: description: Example Project # Allow manifests to deploy from any Git repos sourceRepos: - * destinations: - namespace: * server: https://kubernetes.default.svc destinationServiceAccounts: - namespace: * server: https://kubernetes.default.svc defaultServiceAccount: generic-deployer此场景中namespace: *是第一个也是唯一有效匹配因此generic-deployer会被用于同步。示例 2AppProject 级对指定命名空间指定同步服务账号场景服务账号名guestbook-deployer将用于应用同步因为命名空间guestbook精确匹配目标命名空间guestbook。安装与启用步骤同示例 1随后kubectl create namespace guestbook kubectl create serviceaccount guestbook-deployerkubectl create role guestbook-deployer-role --verb get,list,update,delete --resource pods,deployment,service kubectl create rolebinding guestbook-deployer-rb --serviceaccount guestbook-deployer --role guestbook-deployer-role此场景下guestbook-deployer精确匹配命名空间guestbookapiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd spec: project: my-project source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc namespace: guestbook --- apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: description: Example Project # Allow manifests to deploy from any Git repos sourceRepos: - * destinations: - namespace: guestbook server: https://kubernetes.default.svc - namespace: guestbook-ui server: https://kubernetes.default.svc destinationServiceAccounts: - namespace: guestbook server: https://kubernetes.default.svc defaultServiceAccount: guestbook-deployer - namespace: guestbook-ui server: https://kubernetes.default.svc defaultServiceAccount: guestbook-ui-deployer示例 3远端集群 默认 argocd-managercluster-admin注意本示例依赖通过 Argo CD CLI 添加远端集群时创建的默认 ServiceAccountargocd-manager具备cluster-admin权限。argocd cluster add remote-cluster --name remote-cluster说明上述命令会在kube-system命名空间创建名为argocd-manager的 ServiceAccount、名为argocd-manager-role的 ClusterRole完整集群管理员权限以及名为argocd-manager-role-binding的 ClusterRoleBinding将argocd-manager-role绑定到服务账号remote-cluster。在远端集群中创建命名空间与服务账号kubectl ctx remote-cluster kubectl create namespace guestbook kubectl create serviceaccount guestbook-deployer在远端集群中配置 RBACkubectl ctx remote-cluster kubectl create role guestbook-deployer-role --verb get,list,update,delete --resource pods,deployment,service kubectl create rolebinding guestbook-deployer-rb --serviceaccount guestbook-deployer --role guestbook-deployer-role创建 Application 与 AppProjectapiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd spec: project: my-project source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc namespace: guestbook --- apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: description: Example Project # Allow manifests to deploy from any Git repos sourceRepos: - * destinations: - namespace: guestbook server: https://kubernetes.default.svc destinationServiceAccounts: - namespace: guestbook server: https://kubernetes.default.svc defaultServiceAccount: guestbook-deployer示例 4远端集群 自定义服务账号非 cluster-admin注意本示例为同步操作使用目标集群与命名空间中创建的非默认服务账号guestbook适用于远端集群由不同管理员管理、无法提供 cluster-admin 级服务账号的场景。在远端集群创建具备伪装权限的服务账号argocd-adminkubectl ctx remote-cluster kubectl create serviceaccount argocd-admin kubectl create clusterrole argocd-admin-role --verbimpersonate --resourceusers,groups,serviceaccounts kubectl create clusterrole argocd-admin-role-access-review --verbcreate --resourceselfsubjectaccessreviews kubectl create clusterrolebinding argocd-admin-role-binding --serviceaccount argocd-admin --clusterrole argocd-admin-role kubectl create clusterrolebinding argocd-admin-access-review-role-binding --serviceaccount argocd-admin --clusterrole argocd-admin-role关键点argocd-admin需要具备impersonate动词权限针对users、groups、serviceaccounts以及创建selfsubjectaccessreviews的权限Kubernetes 在发起伪装请求时会先执行 SubjectAccessReview 检查。在远端集群创建目标命名空间与服务账号kubectl ctx remote-cluster kubectl create namespace guestbook kubectl create serviceaccount guestbook-deployer配置目标服务账号的 RBACkubectl create role guestbook-deployer-role --verb get,list,update,delete --resource pods,deployment,service kubectl create rolebinding guestbook-deployer-rb --serviceaccount guestbook-deployer --role guestbook-deployer-role此场景中guestbook-deployer因精确匹配命名空间guestbook而被使用apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd spec: project: my-project source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc namespace: guestbook --- apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: description: Example Project # Allow manifests to deploy from any Git repos sourceRepos: - * destinations: - namespace: guestbook server: https://kubernetes.default.svc - namespace: guestbook-ui server: https://kubernetes.default.svc destinationServiceAccounts: - namespace: guestbook server: https://kubernetes.default.svc defaultServiceAccount: guestbook-deployer - namespace: guestbook-ui server: https://kubernetes.default.svc defaultServiceAccount: guestbook-ui-deployer特殊场景与匹配规则在其它命名空间指定 ServiceAccount默认情况下ServiceAccount 会在 Application 的目标命名空间Application.Spec.Destination.Namespace中查找。如果 ServiceAccount 位于其它命名空间可用namespace:service_account_name格式显式指定... destinationServiceAccounts: - server: https://kubernetes.default.svc namespace: * defaultServiceAccount: mynamespace:guestbook-deployer ...多个 destination 同时匹配时若同一目标命中多个destinationServiceAccounts条目使用列表中第一个有效匹配。例如... destinationServiceAccounts: - server: https://kubernetes.default.svc namespace: guestbook-prod defaultServiceAccount: guestbook-prod-deployer - server: https://kubernetes.default.svc namespace: guestbook-* defaultServiceAccount: guestbook-generic-deployer - server: https://kubernetes.default.svc namespace: * defaultServiceAccount: generic-deployer ...Application 目标命名空间为myns只有 glob*命中使用generic-deployer目标命名空间为guestbook-dev或guestbook-stage*与guestbook-*都命中但guestbook-*排在更前因此使用guestbook-generic-deployer目标命名空间为guestbook-prod三个都命中但列表中第一个有效匹配是guestbook-prod-deployer故使用它。Git 仓库中资源横跨多个命名空间用于伪装的 ServiceAccount 是按 Application 级别确定的而不是按单个资源级别。Application.spec.destination.namespace的值会用于确定该 Application 内所有资源的同步服务账号——即使 Git 仓库中的某些清单硬编码了其它命名空间。Application 未设置 spec.destination.namespacespec.destination.namespace在Application中是可选字段。未指定时控制器使用Application 自身命名空间中的服务账号执行同步与DeriveServiceAccountToImpersonate中serviceAccountNamespace 时的回退逻辑一致见 impersonation.go用户也可显式指定带命名空间的服务账号。apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd spec: project: my-project source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook destination: server: https://kubernetes.default.svc --- apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd finalizers: - resources-finalizer.argocd.argoproj.io spec: description: Example Project # Allow manifests to deploy from any Git repos sourceRepos: - * destinations: - namespace: guestbook server: https://kubernetes.default.svc - namespace: guestbook-ui server: https://kubernetes.default.svc destinationServiceAccounts: - namespace: guestbook server: https://kubernetes.default.svc defaultServiceAccount: guestbook-deployer - namespace: guestbook-ui server: https://kubernetes.default.svc defaultServiceAccount: guestbook-ui-deployer上例中由于未指定spec.destination.namespace使用 Application 命名空间argocd作为服务账号作用域即system:serviceaccount:argocd:guestbook-deployer会被用于同步。若匹配的服务账号显式带命名空间如guestbook:guestbook-deployer则使用system:serviceaccount:guestbook:guestbook-deployer。安全考量、风险与缓解安全影响启用该特性后Argo CD 工作负载的同步操作以受限身份执行控制平面即使被攻破攻击者能够获得的权限也被限制在目标 ServiceAccount 的 RBAC 范围内显著缩小了爆炸半径。风险权限提升如果允许用户无限制地伪装会引入权限提升风险。缓解措施只有管理员能在AppProject级别配置用于同步的服务账号使用 Kubernetes RBAC 的resourceNames字段限制某个 ServiceAccount 可以伪装的具体对象而不是放任其伪装所有用户/组。例如可以在 ClusterRole 中为impersonate权限指定具体的resourceNames将可伪装范围收敛到特定服务账号。升级 / 降级策略该特性基于 feature flag 采用opt-in默认关闭方式实现新增的AppProject.Spec字段是可选的只有显式开启 feature flag 后才生效若在 CR 中使用了新字段但未开启 feature flag则在 CR 调和reconcile期间会显示警告消息升级到启用 Impersonation 的版本后未配置destinationServiceAccounts的现有 AppProject 行为保持不变回退到默认default服务账号或依据enforced配置处理。已知取舍Drawbacks使用该特性需要额外维护命名空间、ServiceAccount、相应 RBAC 策略并将 ServiceAccount 与AppProject配置一一对应存在一定的运维开销。备选方案与设计取舍备选方案完整暴露 ImpersonationConfig一种更激进的方案是向用户暴露ImpersonationConfig的全部选项用户名、UID、组apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd spec: description: Example Project # Allow manifests to deploy from any Git repos sourceRepos: - * destinations: - namespace: * server: https://kubernetes.default.svc namespace: guestbook impersonate: user: system:serviceaccount:dev_ns:admin uid: 1234 groups: - admin - view - edit该方案未被采纳以保持初始设计的最小化将来可根据需求与反馈再支持用户/组的伪装。设计决策要点源码与提案相互印证不扩展destinations字段该字段的语义是限制 Application 可用的目标且支持!否定运算符会复杂化服务账号匹配逻辑因此在AppProject.Spec下新增独立结构字段名选用defaultServiceAccount而非serviceAccount为将来在 Application 级别覆盖服务账号预留serviceAccount名称全局项目继承destinationServiceAccounts已纳入全局项目Global Projects可继承字段列表见 projects.md与destinations等字段一并支持从全局项目继承方便统一管理。未来增强提案规划的未来方向包括在 Application 级别支持覆盖服务账号届时将向AppProject.spec.destinationServiceAccounts[*]增加allowedServiceAccounts元素。延伸阅读提案全文decouple-application-sync-user-using-impersonation.mdAPI 结构体定义types.goAppProject 校验逻辑app_project_types.go服务账号推导算法impersonation.go功能开关与强制策略settings.go同步路径伪装实现sync.goServer-Side Diff 伪装实现sync.go控制器的伪装配置应用appcontroller.goAppProject 用户指南含全局项目继承字段说明projects.md【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考