云原生后端开发工具微服务【免费下载链接】operator-sdkSDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.项目地址https://gitcode.com/gh_mirrors/op/operator-sdk点击查看免费下载Operator 在集群中运行时通常会借助一个主 ServiceAccount由 Deployment 的serviceAccountName指定获得执行调谐所需的权限。但在实际生产环境中Operator 创建的对象可能横跨多个命名空间、涉及 OpenShift 安全上下文约束SCC等特殊资源单一账户的权限要么过大、要么不足。Operator-SDK 提供了operator-sdk generate bundle的--extra-service-accounts标志让你可以在生成 BundleClusterServiceVersion / CSV时将额外的 ServiceAccount 及其绑定的 Role/ClusterRole 权限一并纳入 CSV实现一个 Operator、多个最小权限账户的部署形态。本文以仓库文档 multi-sa.md 为主线结合源码讲解该标志的完整配置流程、底层权限归并逻辑与测试验证读完即可在自己的 Operator 项目中落地多 ServiceAccount 方案。为什么需要多个 ServiceAccountKubernetes 中的 ServiceAccount 是 Pod 访问 API Server 的身份凭证。默认情况下使用operator-sdk init脚手架创建的 Operator 只有一个 Deployment 账户所有由该 Operator 创建的 Pod、Job、CronJob 等负载如果复用同一账户就会继承过宽的权限面。文档明确指出There may be a need to have multiple service accounts to provide only the necessary permissions to various objects that the operator creates on a Kubernetes cluster.即Operator 创建的不同对象可能需要不同的权限集合通过为它们分配独立的 ServiceAccount可以将权限精确限定到该对象完成工作所必需的最小范围。这在以下场景尤为典型Operator 在目标命名空间创建执行任务的 Pod需要访问特定 ConfigMap/Secret但不应该拥有集群级管理权限在 OpenShift 上运行的 Operator 需要为某些工作负载授予privilegedSCCSecurityContextConstraint但不应将这种高风险权限授予 Operator 自身账户。--extra-service-accounts标志是什么在 cmd.go 中可以看到该标志的准确定义fs.StringSliceVar(c.extraServiceAccounts, extra-service-accounts, nil, Names of service accounts, outside of the operators Deployment account, that have bindings to {Cluster}Roles that should be added to the CSV)关键信息有三点类型为StringSliceVar接受以逗号分隔的字符串列表因此可以在一次生成中指定多个额外账户例如--extra-service-accounts sa-a,sa-b,sa-c默认值为nil不指定时行为与旧版本完全一致只处理 Deployment 引用的那个账户作用范围这些账户是Deployment 账户之外的账户它们通过 RoleBinding / ClusterRoleBinding 绑定的 {Cluster}Role 会被收集进生成的 CSV 权限字段。CLI 参考文档 operator-sdk_generate_bundle.md 中给出的说明与之完全一致这些账户是拥有 {Cluster}Roles 绑定、应被添加到 CSV 的 ServiceAccount 名称。第一步更新 Makefile 的 bundle 目标为了让权限配置在每次重新生成 Bundle 时不被覆盖文档建议修改项目Makefile中的bundle目标把标志固化进去bundle: manifests kustomize operator-sdk ## Generate bundle manifests and metadata, then validate generated files. operator-sdk generate kustomize manifests -q cd config/manager $(KUSTOMIZE) edit set image controller$(IMG) $(KUSTOMIZE) build config/manifests | operator-sdk generate bundle -q --overwrite --extra-service-accounts myOperator-name-additional-service-account --version $(VERSION) $(BUNDLE_METADATA_OPTS) operator-sdk bundle validate ./bundle其中myOperator-name-additional-service-account需要替换为附加到 Operator 名称之后的账户名。整条链路为operator-sdk generate kustomize manifests -q刷新 kustomize manifestskustomize edit set image把管理器镜像更新为最新构建的$(IMG)kustomize build config/manifests | operator-sdk generate bundle ...构建清单并通过管道交给 bundle 生成器--overwrite允许覆盖已存在的 Bundle 元数据与 Dockerfilecmd.go 中该标志默认即为trueoperator-sdk bundle validate ./bundle生成后立即校验 Bundle 合法性。由于--extra-service-accounts是幂等生成流程的一部分每次运行make bundle都会重新应用该账户列表因此手工修改生成的 CSV 不会在下一次生成时被保留——正确做法就是把账户声明固化在 Makefile 中。第二步为每个额外账户创建 RBAC 资源文档强调以下步骤需要对每一个额外的 ServiceAccount 重复执行。1. 创建 ServiceAccountcat EOF config/rbac/additional_service_account.yaml apiVersion: v1 kind: ServiceAccount metadata: name: additional-service-account namespace: system EOF命名空间system是 kustomize 默认的替换占位符make bundle时会被替换为实际部署命名空间。2. 创建角色绑定RoleBinding 或 ClusterRoleBinding文档示例使用ClusterRoleBinding将账户绑定到集群级角色cat EOF config/rbac/additional_role_binding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: additional-service-account-rolebinding roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: additional-service-account-role subjects: - kind: ServiceAccount name: additional-service-account namespace: system EOF如果只需要命名空间内权限改用RoleBinding并让roleRef.kind: Role即可。注意绑定是 CSV 权限归并的关键入口生成器正是通过绑定中的 ServiceAccount subject反查角色的。3. 创建带目标权限的角色文档示例创建一个ClusterRole仅授予对 OpenShiftprivilegedSCC 的use权限cat EOF config/rbac/additional_role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: creationTimestamp: null name: additional-service-account-role rules: - apiGroups: - security.openshift.io resourceNames: - privileged resources: - securitycontextconstraints verbs: - use EOF这是多 ServiceAccount 最典型的实战用途Operator 自身账户保持低权限而需要运行特权容器的工作负载单独绑定一个仅含securitycontextconstraints/use权限的账户把高敏感权限限制在最小范围内。第三步把 RBAC 文件注册进 kustomization.yaml新创建的三个文件必须登记到 RBAC 的 kustomization 中否则kustomize build config/manifests不会收集它们cat EOF config/rbac/kustomization.yaml # Add MyCustomObject service account - additional_service_account.yaml - additional_role.yaml - additional_role_binding.yaml EOF对应的可参考仓库结构是 testdata/go/v4/memcached-operator/config/rbac脚手架默认的 RBAC 目录正是config/rbac其中包含service_account.yaml、role.yaml、role_binding.yaml等基础文件新增文件遵循同样的组织方式即可。源码原理CSV 如何归并账户与权限理解了配置流程后再深入源码看--extra-service-accounts到底做了什么。核心逻辑在 clusterserviceversion.go 的SplitCSVPermissionsObjects(extraSAs []string)// Create a set of ServiceAccount names to match against below. csvSAs : make(map[string]struct{}) for _, dep : range c.Deployments { saName : dep.Spec.Template.Spec.ServiceAccountName if saName { saName defaultServiceAccountName // default } csvSAs[saName] struct{}{} } for _, extraSA : range extraSAs { csvSAs[extraSA] struct{}{} }这段代码揭示了归并规则生成器首先收集所有 Deployment 的serviceAccountName未显式指定时按default处理作为CSV 内账户集合再把--extra-service-accounts传入的账户名并入同一个集合然后遍历所有 RoleBinding / ClusterRoleBinding凡是 subject 中出现了集合内账户名的绑定其roleRef指向的 Role / ClusterRole 就会被归入 CSV 的spec.install.spec.permissions命名空间级或clusterPermissions集群级未被任何集合内账户绑定的 Role / ClusterRole、以及绑定了非集合账户的绑定对象则被归入out由 manifests.go 中的GetManifestObjects原样写入 Bundle 的 manifests 目录bundle/manifests/不进入 CSV 权限字段。函数注释对此总结得很精确clusterserviceversion.goSplitCSVPermissionsObjects splits Roles and ClusterRoles bound to ServiceAccounts in Deployments and extraSAs. Roles and ClusterRoles bound to RoleBindings associated with ServiceAccounts are added to inPerms. ClusterRoles bound to ClusterRoleBindings associated with ServiceAccounts are added to inCPerms.而ExtraServiceAccounts字段在 clusterserviceversion.go 中的注释同样点明它们是在通过 Bindings 匹配要纳入 CSV 的 {Cluster}Roles 时需要考虑的 ServiceAccount 名称。此外manifests.go 中removeNamespace会把写入 manifests 目录的对象 namespace 清空——这是为了通过 OLM 校验因为命名空间资源由 OLM 在安装时动态注入。测试验证多账户权限归并行为仓库中的单元测试 clusterserviceversion_test.go 直接验证了上述行为。测试构造了my-dep-accountDeployment 账户与my-other-account额外账户两个 ServiceAccount以及一组交错绑定的 Role/ClusterRole当只传 Deployment 账户SplitCSVPermissionsObjects(nil)时role2、clusterrole2以及相关的绑定、my-other-account本身全部落入out即被排除在 CSV 之外当传入[]string{my-other-account}时role1、role2进入inPermsclusterrole1、clusterrole2进入inCPermsout为空——所有权限都被正确吸收进 CSV。这从测试层面印证了多账户场景下权限全量归并、账户与绑定正确入 CSV的实现事实。生成后的结果与验证执行make bundle后建议从两个方面验证查看 CSV 权限字段打开bundle/manifests/operator-name.clusterserviceversion.yaml在spec.install.spec下应能看到permissions与额外账户存在 RoleBinding 关联的 Role 规则clusterPermissions与额外账户存在 ClusterRoleBinding 关联的 ClusterRole 规则如文档示例中的 SCCuse权限deployments段仍指向 Operator 自身的 Deployment 与主账户。查看 manifests 目录bundle/manifests/下会额外写出未被 CSV 吸收的 RBAC 对象manifests.go它们由 OLM 安装时一并部署。同时make bundle末尾的operator-sdk bundle validate ./bundle会执行 OLM 相关校验若有权限字段格式问题会直接报错是每轮修改后的必要检查步骤。注意事项小结--extra-service-accounts接受逗号分隔的多个账户名StringSliceVar类型见 cmd.go一次可声明多个每个额外账户都需要独立完成ServiceAccount 绑定 角色 kustomization 注册四步缺一不可只有绑定中 subject 包含目标账户的 Role/ClusterRole 才会被写入 CSV与任何已声明账户无关的 RBAC 会被原样放入 Bundle manifests 而非 CSV账户名单应固化在Makefile的bundle目标中否则重新生成时手工改动会被覆盖生成器将 Deployment 未显式指定serviceAccountName视为default见 clusterserviceversion.go因此显式声明账户名有助于避免歧义。通过以上配置你的 Operator 可以在保持自身低权限的同时为集群内不同职责的工作负载分别授予恰如其分的权限实现真正意义上的多 ServiceAccount 最小权限部署。赞分享云原生后端开发工具微服务【免费下载链接】operator-sdkSDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.项目地址https://gitcode.com/gh_mirrors/op/operator-sdk点击查看免费下载相关推荐Argo Workflows 服务账户ServiceAccount配置实战指南RBAC 绑定、权限模型与最小权限实践Argo Workflows 服务账户ServiceAccount配置实战指南RBAC 绑定、权限模型与最小权限实践 导读 本文围绕 Argo Workf云原生容器编排工作流自动化任务调度后端Apache Airflow 自定义 Operator 附加链接Extra Links为任务 UI 增加外部系统入口Apache Airflow 自定义 Operator 附加链接Extra Links为任务 UI 增加外部系统入口 Apache Airflow 的 O后端任务调度工作流自动化数据编排批处理数据工程流程编排Astro Storefront图像优化技巧利用astro:assets提升网站性能Astro Storefront图像优化技巧利用astro:assets提升网站性能 在现代电商网站开发中图像优化是提升网站性能的关键因素之一。Astro上一篇Feishin自托管音乐播放器3步快速配置终极指南 下一篇GROOPS深度解析从重力场恢复到GNSS处理的终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考