通过身份验证的用户仍然可以创建Kubernetes吊舱，尽管存在限制PodSecurityPolicy。

Question

我正试图在一个裸金属Kubernetes 1.18.3集群上开始使用PodSecurityPolicy，该集群由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 - <

这两个已创建的容器都带有注释kubernetes.io/psp: unrestricted，而我则希望在用户user通过身份验证时创建pod/unrestricted以失败。在kubectl create deployment中，事情如预期的那样工作(例如，在命名空间restricted中，serviceaccount:default间接地创建了受限的、无限制的部署，分别成功和失败。不知何故，用户(但不是服务帐户)似乎被绑定到过于广泛的安全策略。

我遗漏了什么？如何进一步诊断和解决该问题(即防止serviceaccount/default in namespace/restricted和用户user在namespace/restricted中创建特权荚)？

更新我想我现在已经隔离到根本原因，但还不知道一个好的解决方案。resources: ["*"]，verbs: ["*"] in role/user似乎也向use any (集群范围内)资源psp授予权限。这是意料之外的:我希望role/user允许user在namespace/restricted中进行“通常”的活动，而不是让它把每个人和任何psp都放进去。

Answer 1

诊断(参见更新)是正确的。解决方案包括从专有的role/user (包含太多权限的{apiGroups: ["*"], resources: ["*"], verbs: ["*"]}切换到Kubernetes默认clusterrole/edit )(特别不包括apiGroup："policy"、resource："podsecuritypolicy"、verb："use" )。