External Secrets Operator 多租户部署模式详解三种隔离架构与 RBAC 落地实践【免费下载链接】external-secretsExternal Secrets Operator reads information from a third-party service like AWS Secrets Manager and automatically injects the values as Kubernetes Secrets.项目地址: https://gitcode.com/GitHub_Trending/ex/external-secretsExternal Secrets OperatorESO通过SecretStore/ClusterSecretStore两类资源抽象了对外部密钥服务的访问天然支持多种多租户形态。本篇指南基于 docs/guides/multi-tenancy.md 展开系统讲解共享 ClusterSecretStore、每命名空间托管 SecretStore、ESO as a Service 三种部署模式的架构、适用场景与权衡并深入仓库源码与配套示例说明conditions、controllerClass、Helm 开关、Kyverno 准入校验等机制如何配合实现租户隔离。读完本文你将能根据组织角色结构与外部 API 的访问控制粒度选型并落地一套适合自己团队的多租户方案。一、多租户设计先分析组织再选择模式ESO 提供多种运行模式以满足不同的组织需求。在动手部署前建议先审视你的组织结构明确三个问题组织中存在哪些角色例如Application Developers应用开发者、Cluster Admins集群管理员、Secret Administrator密钥管理员这些角色各自承担什么职责例如谁负责创建命名空间、谁负责管理外部密钥、谁只负责引用密钥这些职责如何映射到 Kubernetes RBAC 角色即谁有权限创建ClusterSecretStore、SecretStore、ExternalSecret等资源。同时还需要审视外部 API 提供商对密钥的访问控制能力能否按密钥名做细粒度限制例如仅允许db/dev/*前缀还是只能在桶bucket级别控制访问需要注意并非所有外部 API 都提供密钥级的细粒度访问管理。从源码结构看这两类资源在设计上就对应了不同的职责边界secretstore_types.go 中SecretStore是命名空间级资源scopeNamespacedshortName 为ss而ClusterSecretStore是集群级资源scopeClustershortName 为css二者共享同一个SecretStoreSpec。ExternalSecret通过secretStoreRef引用它们其中kind字段默认值为SecretStore可显式指定为ClusterSecretStore参见 externalsecret_types.go。注意下面介绍的示例不应被视为最佳实践的唯一答案它们更多是展示如何组合不同的机制与技术来实现租户隔离。实际选型应以你的组织结构和安全要求为准。二、模式一共享 ClusterSecretStoreShared ClusterSecretStore工作方式集群管理员部署一个ClusterSecretStoreCSS并统一管理对外部 API 的访问。该 CSS 被集群内所有租户共享应用开发者在自己的命名空间里创建ExternalSecret并引用它但不能自行创建ClusterSecretStore或SecretStore。此时所有应用开发者都能访问 CSS 背后的全部密钥。一个典型的共享 CSS 示例AWS Secrets ManagerapiVersion: external-secrets.io/v1 kind: ClusterSecretStore metadata: name: global-aws-store spec: provider: aws: service: SecretsManager region: eu-central-1 auth: secretRef: accessKeyIDSecretRef: name: aws-secret key: access-key namespace: eso-system secretAccessKeySecretRef: name: aws-secret key: secret-access-key namespace: eso-system --- # 租户侧只需引用即可无需也无法创建 Store apiVersion: external-secrets.io/v1 kind: ExternalSecret metadata: name: app-secret namespace: team-a spec: secretStoreRef: name: global-aws-store kind: ClusterSecretStore target: name: app-secret data: - secretKey: db_password remoteRef: key: team-a/db_password关键约束没有按命名空间限制密钥的能力ESO 本身不提供按命名空间限制可访问的密钥的机制。这意味着一旦某个命名空间能引用该 CSS它就能读取其背后的全部密钥。如果你希望限制不同租户只能读取特定 key 或特定前缀必须引入 Admission Webhook 做更高级的校验例如使用 Kyverno 或 Open Policy Agent见下文第五节。权限集中在外部 API 侧访问控制实际取决于 CSS 中配置的凭证在外部系统如 AWS IAM中的权限范围。适用场景与取舍适合你有一个包含所有密钥的中央存储桶且希望由集群管理员统一管理对其的访问。优点部署极简租户接入成本低。缺点扩展性差——所有租户共享同一份凭证与权限面一旦需要细化隔离只能依赖外部准入策略。三、模式二每命名空间托管 SecretStoreManaged SecretStore per Namespace工作方式集群管理员为每个命名空间或每组命名空间管理一个或多个SecretStore。每个SecretStore使用独立的 role角色该角色在外部 API 侧被限制为只能访问一小部分密钥。此方案的独特之处在于访问控制实际上由外部 API 提供的角色来管理集群管理员只做接线wiring工作——把正确的角色凭证接入对应命名空间的SecretStore。apiVersion: external-secrets.io/v1 kind: SecretStore metadata: name: team-a-store namespace: team-a spec: provider: aws: service: SecretsManager region: eu-central-1 auth: secretRef: accessKeyIDSecretRef: name: aws-secret key: access-key namespace: team-a secretAccessKeySecretRef: name: aws-secret key: secret-access-key namespace: team-a --- apiVersion: external-secrets.io/v1 kind: ExternalSecret metadata: name: app-secret namespace: team-a spec: secretStoreRef: name: team-a-store kind: SecretStore target: name: app-secret dataFrom: - extract: key: team-a/*职责边界Secret Administrator密钥管理员管理密钥的访问与生命周期——这是一个外部实体负责在外部 API 侧维护角色权限、创建/轮换密钥。Cluster Administrator集群管理员只负责把对应的角色凭证与命名空间绑定创建SecretStore。Application Developer应用开发者在命名空间内创建ExternalSecret引用本命名空间的SecretStore。适用场景与取舍适合组织内存在独立的密钥管理团队希望由外部实体负责密钥的访问与生命周期Kubernetes 侧仅做绑定。优点租户间隔离粒度细隔离责任由外部 API 的角色体系承担Kubernetes 侧只需保证 RBAC 不允许开发者越权创建或修改SecretStore。缺点运维成本高于模式一——每个命名空间都需要单独的凭证/角色管理命名空间数量增长时Store 的数量也随之线性增长。四、模式三ESO as a Service自服务模式工作方式每个命名空间完全自包含。应用开发者自行管理SecretStore、ExternalSecret以及外部密钥基础设施集群管理员只提供 External Secrets Operator 这一公共服务as a Service不再介入具体的 Store 与密钥配置。# 由应用开发者创建于自己的命名空间 apiVersion: external-secrets.io/v1 kind: SecretStore metadata: name: my-store namespace: team-a spec: provider: vault: server: https://vault.example.com path: secret/data/team-a version: v2 auth: kubernetes: mountPath: kubernetes role: team-a-reader --- apiVersion: external-secrets.io/v1 kind: ExternalSecret metadata: name: my-app-secret namespace: team-a spec: secretStoreRef: name: my-store kind: SecretStore target: name: my-app-secret data: - secretKey: api_token remoteRef: key: team-a/api-token适用场景与取舍适合应用开发者应完全自治自行决定密钥来源、命名、轮换策略而由中央团队提供通用平台服务本例中即 ESO 本身。优点平台团队负担最轻租户自主性最高隔离边界清晰——每个命名空间的 Store 只影响自己。缺点对外部 API 凭证的管理分散在各租户手中若缺乏治理可能出现凭证泄露、密钥命名混乱等风险需要靠 RBAC 与准入策略兜底。五、三种模式的组合与深化机制多租户落地往往不是单选一种模式而是组合多种机制。以下是仓库中可直接使用的配套能力。5.1 用 Helm 开关裁剪集群级功能如果采用ESO as a Service或每命名空间托管模式你可能希望彻底禁用ClusterSecretStore、ClusterExternalSecret、ClusterPushSecret等集群级资源避免租户间共享或误用。参考 docs/guides/disable-cluster-features.md需要通过 Helm 同时配置crds.*与process*两组值它们相互关联helm install external-secrets external-secrets/external-secrets \ --set crds.createClusterExternalSecretfalse \ --set crds.createClusterSecretStorefalse \ --set crds.createClusterPushSecretfalse \ --set processClusterExternalSecretfalse \ --set processClusterStorefalse \ --set processClusterPushSecretfalse这样集群中不再安装这些集群级 CRDoperator 也不会处理它们——从根上杜绝了跨命名空间共享 Store 的可能让每命名空间自服务的边界更清晰。5.2 用 ClusterSecretStore conditions 限定可见命名空间即便保留ClusterSecretStore也可以利用其spec.conditions字段见 secretstore_types.go 与 ClusterSecretStoreCondition 定义将集群级 Store 的效力约束到指定命名空间。该字段支持三种选择方式namespaceSelector按 label selector 匹配命名空间namespaces按名称精确列出命名空间namespaceRegexes按正则匹配命名空间名称。示例——仅让打了tenant: alpha标签的命名空间可用该 CSSapiVersion: external-secrets.io/v1 kind: ClusterSecretStore metadata: name: alpha-only-store spec: conditions: - namespaceSelector: matchLabels: tenant: alpha provider: fake: data: - key: alpha/db_password value: supersecret注意conditions是ClusterSecretStore特有的能力只对集群级 Store 生效。5.3 用 controllerClass 实现多控制器隔离如果希望多个 ESO 控制器实例分管不同的 Store/工作负载组可以借助实验性的Controller Class机制详见 docs/guides/controller-class.md。它通过spec.controller属性将SecretStore归属到特定控制器helm install custom-external-secrets external-secrets/external-secrets --set controllerClasscustomapiVersion: external-secrets.io/v1 kind: SecretStore metadata: name: custom-store namespace: team-a spec: controller: custom provider: fake: data: - key: foo value: bar此后绑定到该 Store 的ExternalSecret只会被controllerClasscustom的 operator 处理。需要留意的是未设置spec.controller的 Store 会被任意controller 视为有效无论其 controllerClass 是什么该特性目前标注为 experimental尚未经过高强度的测试。5.4 用 Admission Webhook 补齐密钥级隔离如前所述ESO 不提供按命名空间限制密钥前缀的内置能力这类高级校验应交给 Admission Webhook。仓库 docs/snippets/kyverno-policy-secretstore.yaml 提供了一个现成的 KyvernoClusterPolicy示例强制所有SecretStore/ClusterSecretStore只能使用 AWS Secrets Manager 提供商apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: require-secretstore-aws-provider spec: validationFailureAction: Enforce rules: - name: require-secretstore-aws-provider match: any: - resources: kinds: - SecretStore - ClusterSecretStore validate: message: You must only use AWS SecretsManager pattern: spec: provider: aws: service: SecretsManager以此类推你可以编写更细粒度的策略例如校验remoteRef.key必须匹配team-namespace/*前缀、校验spec.provider中引用的凭证 Secret 必须位于固定命名空间等从而在共享 CSS模式下实现前缀级租户隔离。使用 OPAGatekeeper也能达到同样目的。六、模式对比与选型建议维度共享 ClusterSecretStore每命名空间托管 SecretStoreESO as a ServiceStore 归属集群管理员集群级集群管理员命名空间级应用开发者命名空间级访问控制主体外部 API 凭证 准入策略外部 API 的角色体系租户自管理凭证隔离粒度粗需 Webhook 补强细按角色限 key细命名空间自包含集群管理员负担低中低租户自主性低中高适合组织单一中央密钥桶有独立密钥管理员平台 自治租户选型时请重点回答两个问题谁负责密钥的访问与生命周期如果是中央团队倾向模式一或二如果是租户自身选模式三。外部 API 的访问控制粒度如何支持密钥前缀级角色如 Vault 的 policy、AWS IAM 的 resource 限制时模式二能获得真正的细粒度隔离仅桶级访问时模式一配合 Kyverno/OPA 做准入校验是更务实的组合。七、安全要点小结最小权限无论是 CSS 的共享凭证还是每命名空间的 role都应在外部 API 侧收紧到只读所需密钥。RBAC 兜底通过 Kubernetes RBAC 限制ClusterSecretStore/SecretStore的 create/update 权限只授予集群管理员应用开发者仅能创建ExternalSecret。准入策略用 Kyverno / OPA 补齐 ESO 不提供的按命名空间限制密钥前缀能力参考 kyverno-policy-secretstore.yaml 的模式扩展。裁剪攻击面不需要集群级功能时用 5.1 节的 Helm 参数关闭对应 CRD 与处理逻辑。组合而非单选三种模式不是互斥的你可以共享 CSS conditions 限定命名空间 Webhook 前缀校验组合使用也可以为高敏租户单独走每命名空间托管为普通租户开放自服务。参考与延伸阅读关联文档docs/guides/multi-tenancy.mdAPI 类型定义apis/externalsecrets/v1/secretstore_types.goSecretStore/ClusterSecretStore/conditions、apis/externalsecrets/v1/externalsecret_types.gosecretStoreRef裁剪集群级功能docs/guides/disable-cluster-features.md控制器隔离docs/guides/controller-class.md准入策略示例docs/snippets/kyverno-policy-secretstore.yaml跨命名空间分发ClusterExternalSecret Kubernetes Providerdocs/snippets/cluster-external-secret-fanout.yaml完整配置样例docs/snippets/full-secret-store.yaml、docs/snippets/full-cluster-secret-store.yaml【免费下载链接】external-secretsExternal Secrets Operator reads information from a third-party service like AWS Secrets Manager and automatically injects the values as Kubernetes Secrets.项目地址: https://gitcode.com/GitHub_Trending/ex/external-secrets创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
