Argo CD 如何开启 Web-based Terminal 并配置 exec RBAC 权限【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cdArgo CD 从 v2.4 开始提供 Web-based Terminal用户在浏览器里直接获取一个 Application 所管理的运行中 Pod 的 shell效果类似kubectl exec并且支持完整 ANSI 颜色。出于安全考虑该功能默认关闭。开启它需要两步在argocd-cmConfigMap 中打开exec.enabled再为需要使用该功能的用户配置exec资源的 RBAC 策略create动作。如果目标集群的 Kubernetes 版本低于 1.31还需要额外给argocd-server补充pods/exec的 Kubernetes 权限。在动手之前需要明确一点这是一个高权限功能。文档明确指出拥有exec/create权限的用户可以在任意受管 Pod 中运行任意代码如果 Pod 挂载了 ServiceAccount token这是 Kubernetes 的默认行为用户实际上就拥有该 ServiceAccount 的同等权限。因此只应对确有需要的人员开放并按应用范围授权。前提条件Argo CD 版本不低于 v2.4该功能自 v2.4 引入。集群中已有一个处于运行状态的、归属于某 Application 的 Pod。若要通过 RBAC 授权给 SSO 组或本地用户需要先完成 SSO 配置或建立本地用户Argo CD 没有独立的用户管理系统内置admin用户本身拥有不受限权限。确认目标集群 Kubernetes 版本它决定是否需要第二步的pods/exec补丁自 Kubernetes 1.31 起get权限就足够 exec 进容器无需额外权限1.31 以下必须补充。第一步在 argocd-cm 中开启 exec 并重启在argocd-cmConfigMap 的data中把exec.enabled设为trueapiVersion: v1 kind: ConfigMap metadata: name: argocd-cm namespace: namespace # Replace namespace with your actual namespace data: exec.enabled: true其中namespace是文档示例中要求替换的占位符填入你的 Argo CD 实际安装命名空间即可。该键的默认值是false完整字段含义见 argocd-cm.yaml 示例。修改后按照 Web-based Terminal 文档 的要求重启 Argo CD 使配置生效。文档只要求重启服务没有给出具体命令按你实际的部署方式重启相关组件即可。第二步Kubernetes 1.31 以下补充 argocd-server 的 exec 权限如果你的集群是 Kubernetes 1.31 或更高版本跳过本节。低版本集群需要让argocd-server有权exec进 pods文档给出的权限规则是- apiGroups: - resources: - pods/exec verbs: - create把它加到argocd-server的 Rolenamespaced 安装或 ClusterRoleclustered 安装中。文档同时提供了等价的即时 patch 命令argocd-server-role-name/argocd-server-clusterrole-name替换为你环境中真实的 Role / ClusterRole 名称namespaced Argokubectl patch role argocd-server-role-name -n argocd --typejson -p[{op: add, path: /rules/-, value: {apiGroups: [*], resources: [pods/exec], verbs: [create]}}]clustered Argokubectl patch clusterrole argocd-server-clusterrole-name --typejson -p[{op: add, path: /rules/-, value: {apiGroups: [*], resources: [pods/exec], verbs: [create]}}]需要注意文档中声明式规则写的apiGroups是核心组而上面两条 patch 示例命令里用的是[*]两种写法都出自同一文档使用时以你实际安装清单中 Role 的既有规则为准。第三步配置 exec RBAC 策略exec是 Application-Specific 资源其 object 格式为app-project/app-name且只有create一个合法动作见 RBAC 文档 中的资源-动作对照表。被授予exec的create后用户就能通过 UI 对该应用的 Pod 执行 exec行为类似kubectl exec。方式一全局策略把策略写入argocd-rbac-cmConfigMap 的policy.csv或其policy.任意字符串.csv叠加键语法见 argocd-rbac-cm.yaml 示例。文档给出的 exec 策略示例p, role:myrole, exec, create, */*, allow这里role:myrole是示例角色名*/*表示所有项目下的所有应用按需收窄例如只允许某个项目p, role:myrole, exec, create, my-project/*, allow。注意Web-based Terminal 文档中写的是该规则可以加到argocd-cmConfigMap 或 AppProject 清单而 RBAC 文档 说明全局策略存放在argocd-rbac-cm。两处表述不一致建议以 RBAC 文档的argocd-rbac-cm为准并自行验证生效情况。另外如果策略的主体是组group必须先通过g, group, role把组绑定到角色否则p, group, ...的规则不会被采用。方式二AppProject 角色按项目收窄推荐在 AppProject 的spec.roles中定义角色角色策略只能授予该角色自身权限且策略必须限定在本项目内。文档中的示例来自 projects.mdapiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd spec: roles: - name: myrole description: Exec access to my-project policies: - p, proj:my-project:myrole, exec, create, my-project/*, allow groups: - my-oidc-group注意角色策略必须遵循proj:project-name:role-name的模式才会在授权时生效。用户与角色的关联通过groups列表动态生成。也可以用argocd proj role系列 CLI 命令在界面上管理角色但注意每个项目角色策略只能作用于其所属项目跨项目规则仍需写到argocd-rbac-cm。验证与失败现象文档给出的行为判定如下配置生效后具有exec/create权限的用户在 UI 的 Terminal 页面对运行中的 Pod 打开 shell即视为功能可用如文首截图所示。若 Pod 中找不到任何允许的 shell终端会话会失败这是文档明确列出的失败现象。反向验证未授予exec/create策略的用户不应能打开终端——这直接由 RBAC 授权模型决定exec 资源默认没有任何隐式权限。可选调整允许的 shell 顺序Argo CD 默认按以下顺序尝试执行 shellbash、sh、powershell、cmd全部找不到时终端会话失败。要增删或改序修改argocd-cm中的exec.shells键值用逗号分隔data: exec.shells: bash,sh,powershell,cmd限制与安全边界权限边界等于 ServiceAccount只要 Pod 挂载了 ServiceAccount tokenK8s 默认行为能 exec 的用户就等价于持有该 ServiceAccount 的权限。授权时应假设用户可完全操控 Pod 内进程。版本边界Kubernetes 1.31 是分界线——1.31 及以下必须完成第二步的 Role/ClusterRole 补丁否则argocd-server无法完成 exec。exec资源只接受create动作不存在get/update/delete等其它形式配置时不要照搬其他资源的策略写法。【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考