Прошедший аутентификацию пользователь по-прежнему может создавать поды Kubernetes, несмотря на наличие ограниченного PodSecurityPolicy.

Я пытаюсь начать с PodSecurityPolicy на чистом кластере Kubernetes 1.18.3 с управлением пользователями, обеспечиваемым Keycloak. psp/restricted должен применяться в namespace/restricted (как для конкретного пользователя user и пространство имен serviceaccount/default) , и psp/unrestricted должен применяться в namespace/unrestricted. У меня основы работают (приемный контролер PodSecurityPolicy установлен и т. д.), и имеются следующие ресурсы:

apiVersion: v1
kind: List
items:
- kind: Role
  apiVersion: rbac.authorization.k8s.io/v1
  metadata:
    name: user
    namespace: restricted
  rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]
- kind: RoleBinding
  apiVersion: rbac.authorization.k8s.io/v1
  metadata:
    name: user
    namespace: restricted
  subjects:
  - kind: Group
    name: user
    apiGroup: rbac.authorization.k8s.io
  roleRef:
    kind: Role
    name: user
    apiGroup: rbac.authorization.k8s.io
- kind: PodSecurityPolicy
  apiVersion: policy/v1beta1
  kind: PodSecurityPolicy
  metadata:
    name: restricted
  spec:
    privileged: false
    seLinux:
      rule: RunAsAny
    supplementalGroups:
      rule: RunAsAny
    runAsUser:
      rule: RunAsAny
    fsGroup:
      rule: RunAsAny
    volumes:
    - '*'
- kind: PodSecurityPolicy
  apiVersion: policy/v1beta1
  kind: PodSecurityPolicy
  metadata:
    name: unrestricted
  spec:
    privileged: true
    hostNetwork: true
    seLinux:
      rule: RunAsAny
    supplementalGroups:
      rule: RunAsAny
    runAsUser:
      rule: RunAsAny
    fsGroup:
      rule: RunAsAny
    volumes:
    - '*'
- kind: ClusterRole
  apiVersion: rbac.authorization.k8s.io/v1
  metadata:
    name: restricted
  rules:
  - apiGroups: ["policy"]
    resources: ["podsecuritypolicies"]
    verbs: ["use"]
    resourceNames:
    - restricted
- kind: ClusterRole
  apiVersion: rbac.authorization.k8s.io/v1
  metadata:
    name: unrestricted
  rules:
  - apiGroups: ["policy"]
    resources: ["podsecuritypolicies"]
    verbs: ["use"]
    resourceNames:
    - unrestricted
- kind: ClusterRoleBinding
  apiVersion: rbac.authorization.k8s.io/v1
  metadata:
    name: restricted
  subjects:
  - kind: ServiceAccount
    name: default
    namespace: restricted
  - kind: User
    name: user
    apiGroup: rbac.authorization.k8s.io
  roleRef:
    kind: ClusterRole
    name: restricted
    apiGroup: rbac.authorization.k8s.io
- kind: ClusterRoleBinding
  apiVersion: rbac.authorization.k8s.io/v1
  metadata:
    name: unrestrictied
  subjects:
  - kind: Group
    name: system:nodes
    apiGroup: rbac.authorization.k8s.io
  - kind: ServiceAccount
    name: default
    namespace: unrestricted
  roleRef:
    kind: ClusterRole
    name: unrestricted
    apiGroup: rbac.authorization.k8s.io

С точки зрения use разрешение, все выглядит так, как ожидалось, например:

kubectl auth can-i use podsecuritypolicy/restricted --as user --as-group=system:authenticated # yes
kubectl auth can-i use podsecuritypolicy/unrestricted --as user --as-group=system:authenticated # no

Но я наблюдаю, что пока serviceaccount:restricrted:default не может создать привилегированные поды в namespace/restricted, пользователь user очевидно, все еще может (в то время, когда этот пользователь аутентифицирован в кластере):

kubectl create -f - <<EOF # succeeds (as expected)
apiVersion: v1
kind: Pod
metadata:
  name: unprivileged-test-pod
  namespace: restricted
spec:
  containers:
  - name:  pause
    image: k8s.gcr.io/pause
EOF
kubectl create -f - <<EOF # succeeds (unexpected)
apiVersion: v1
kind: Pod
metadata:
  name: privileged-test-pod
  namespace: restricted
spec:
  containers:
  - name:  pause
    image: k8s.gcr.io/pause
    securityContext:
      privileged: true
EOF

Оба созданных контейнера имеют аннотацию kubernetes.io/psp: unrestricted, тогда как я ожидал создания pod/unrestricted когда пользователь user аутентифицируется на сбой. Все работает как ожидалось с kubectl create deployment (т.е. создание ограниченных неограниченных развертываний косвенно serviceaccount:default в пространстве имен restricted соответственно. Почему-то кажется, что пользователь (но не учетная запись службы) привязан к слишком широкой политике безопасности.

Что мне не хватает? Как я могу дополнительно диагностировать и решить проблему (т.е. предотвратить оба serviceaccount/default в namespace/restricted и пользователь user от создания привилегированных модулей в namespace/restricted?

ОБНОВИТЬ Я думаю, что сейчас изолировал основную причину, но пока не знаю хорошего решения. Казалось бы, resources: ["*"], verbs: ["*"] в role/user также дает разрешение на use любой (общекластерный) ресурс psp. Это непреднамеренно: я хочу role/user разрешить user "обычные" действия внутри namespace/restrictedне позволяй этому use каждый и любой psp также.