Kubernetes如何限制用户仅可删除自身动态创建的命名空间

原生静态RBAC无法提前绑定未知名称的命名空间权限，要实现提出的三个权限要求，需要组合基础RBAC授权+准入控制器动态策略实现，步骤如下：

1. 配置最小化集群级创建权限 #

首先给目标用户授予仅创建命名空间的集群权限，不要授予集群维度的命名空间删除、查询权限，从基础层避免用户操作非自有命名空间：
对应的ClusterRole配置示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: temp-namespace-creator
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["create"]

将该ClusterRole通过ClusterRoleBinding绑定给目标用户后，用户就具备了创建任意名称命名空间的能力，满足「允许创建随机名称命名空间」的要求，此时用户默认没有删除任何已有命名空间的权限。

2. 强制创建时打身份标签 #

通过准入策略加一层校验：要求用户创建临时命名空间时必须携带两个标签：

• temp-ns: "true"：标识这是临时命名空间
• owner: <当前操作的用户名>：标识命名空间的所属用户
  没有携带这两个标签的命名空间创建请求直接拦截，避免用户逃权。

3. 动态授予自有命名空间全量权限 #

配置准入控制器的资源生成规则，监听临时命名空间的创建事件，当符合标签要求的命名空间创建完成后，自动在该命名空间下生成RoleBinding，将该命名空间的管理员权限绑定给标签中标注的owner用户。
以生产常用的Kyverno为例，对应策略配置如下：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: auto-bind-namespace-owner
spec:
  rules:
  - name: generate-owner-rbac
    match:
      any:
      - resources:
          kinds: ["Namespace"]
          selector:
            matchLabels:
              temp-ns: "true"
    generate:
      kind: RoleBinding
      apiVersion: rbac.authorization.k8s.io/v1
      namespace: "{{request.object.metadata.name}}"
      name: namespace-owner-admin
      data:
        roleRef:
          apiGroup: rbac.authorization.k8s.io
          kind: ClusterRole
          name: admin
        subjects:
        - kind: User
          name: "{{request.object.metadata.labels.owner}}"
          apiGroup: rbac.authorization.k8s.io

这一步执行后，用户创建完随机名称的命名空间，会立刻获得该命名空间的完全操作权限，对其他命名空间无任何访问权限，满足「仅对自身创建的命名空间拥有完全访问权限」的要求。

4. 加一层删除权限兜底校验 #

再配置一条准入校验规则，拦截所有删除命名空间的请求：如果被删除命名空间的owner标签和发起请求的用户名不一致，直接拒绝操作：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-cross-owner-namespace-delete
spec:
  validationFailureAction: Enforce
  rules:
  - name: validate-delete-permission
    match:
      any:
      - resources:
          kinds: ["Namespace"]
    preconditions:
      any:
      - key: "{{request.operation}}"
        operator: Equals
        value: "DELETE"
    validate:
      message: "无权删除非本人创建的命名空间"
      deny:
        conditions:
          any:
          - key: "{{request.object.metadata.labels.owner}}"
            operator: NotEquals
            value: "{{request.userInfo.username}}"

这一层配置完成后，用户只能删除自己作为owner的命名空间，就算基础RBAC配置存在疏漏，也不会出现越权删除其他命名空间的问题，满足「仅可删除自身创建的命名空间」的要求。

如果不想引入Kyverno/OPA Gatekeeper这类第三方准入组件，也可以自行开发轻量Controller，监听Namespace的增删事件，实现同样的自动绑定RoleBinding、删除校验逻辑，核心原理完全一致。

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