如何实现Kubernetes用户专属Secrets隔离？支持自主创建与使用

针对你提出的需求——在Namespace配额有限的情况下，实现K8s用户仅能管理自身NAS凭证Secret，同时借助密钥管理器提升安全性，以下是可落地的具体方案：

核心思路 #

放弃按用户分配独立Namespace的方案，转而在共享Namespace内，通过RBAC资源选择器/ABAC策略实现Secret的归属隔离，同时结合密钥管理器完成凭证的存储、同步与生命周期管理，既满足隔离要求，又节省Namespace资源。

具体实现步骤 #

1. 为Secret绑定用户归属标识 #

要求所有用户创建的NAS凭证Secret必须携带固定标签，例如 owner: <用户名>，以此明确Secret的归属者。后续的权限控制将基于该标签实现。

2. 配置RBAC实现Secret的权限隔离 #

针对K8s 1.26+版本（支持resourceSelectors）

创建通用ClusterRole，限制仅能访问带有自身用户名标签的Secret：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: user-exclusive-secret-manager
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["create", "get", "list", "update", "delete"]
  resourceSelectors:
  - matchLabels:
      owner: "{{user.username}}"

为每个用户绑定该ClusterRole，绑定示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: user-john-secret-binding
subjects:
- kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: user-exclusive-secret-manager
  apiGroup: rbac.authorization.k8s.io

此配置下，用户john仅能操作带有owner: john标签的Secret，无法访问其他用户的Secret。

针对K8s 1.26以下版本

启用ABAC授权模式，编写策略文件限制用户仅能访问自身归属的Secret：

{
  "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
  "kind": "Policy",
  "spec": {
    "user": "john",
    "resource": "secrets",
    "verb": "*",
    "matchLabels": {
      "owner": "john"
    }
  }
}

将该策略文件添加到K8s API Server的--authorization-policy-file参数指定路径，完成权限控制。

3. 结合密钥管理器实现凭证自动化管理 #

以HashiCorp Vault为例，通过Vault CSI Provider实现凭证的自动同步与Secret创建：

1. 在Vault中为每个用户创建独立的NAS凭证存储路径（如secret/data/nas/credentials/john），并配置对应的访问角色。
2. 用户创建SecretProviderClass，指定自身的Vault路径与Secret标签：

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: john-nas-secret
spec:
  provider: vault
  parameters:
    vaultAddress: "http://vault.default.svc.cluster.local:8200"
    roleName: "john-vault-role"
    objects: |
      - objectName: "nas-username"
        secretPath: "secret/data/nas/credentials/john"
        secretKey: "username"
      - objectName: "nas-password"
        secretPath: "secret/data/nas/credentials/john"
        secretKey: "password"
  secretObjects:
  - data:
    - key: username
      objectName: "nas-username"
    - key: password
      objectName: "nas-password"
    secretName: john-nas-secret
    type: Opaque
    labels:
      owner: john

3. 配置Pod通过CSI Volume挂载该Secret，或直接引用Secret环境变量，即可获取NAS凭证。

4. 强制Secret标签合规性 #

使用OPA Gatekeeper配置准入控制策略，防止用户创建不带owner标签或篡改他人标签的Secret：

package kubernetes.admission

deny[msg] {
  input.request.kind.kind == "Secret"
  not input.request.object.metadata.labels.owner == input.request.userInfo.username
  msg := "Secret必须包含与用户名一致的owner标签"
}

该策略会拦截不符合要求的Secret创建/更新请求，确保隔离规则不被绕过。

方案优势 #

• 节省Namespace资源：无需为每个用户分配独立Namespace，避免大量Namespace与对应ClusterRole的维护工作。
• 提升安全性：敏感凭证存储在密钥管理器中，K8s仅同步临时可用的Secret，降低凭证泄露风险。
• 灵活可扩展：用户数量增加时，只需新增密钥管理器角色与RBAC绑定，无需调整Namespace结构。

内容的提问来源于stack exchange，提问作者Alistair McCutcheon