Невозможно переопределить политику безопасности Pod по умолчанию в GKE

Question

Я успешно внедрил PodSecurityPolicies (PSP) в моем локальном мини-кубе, и у меня возникли проблемы с портированием его в GKE. Моя цель сейчас проста -> Не разрешать блоки с UID 0 или с привилегированным доступом.

Мой PSP прост:

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: default-psp
spec:
  privileged: false
  runAsUser:
    rule: MustRunAsNonRoot

И я настроил RBAC ClusterRoleBinding, позволяющий ВСЕМ учетным записям службы использовать PSP.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: restrict-root-clusterRole
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs:     ['use']
  resourceNames:
  - default-psp
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: restrict-root-clusterRoleBinding
roleRef:
  kind: ClusterRole
  name: restrict-root-clusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts

Теперь я включаю PSP в GKE, используя gcloud beta container clusters update psp-demo --enable-pod-security-policy

И тогда я замечаю, что GKE создает следующие PSP

$ k get psp
NAME                           PRIV    CAPS   SELINUX    RUNASUSER   FSGROUP    SUPGROUP   READONLYROOTFS   VOLUMES
gce.event-exporter             false          RunAsAny   RunAsAny    RunAsAny   RunAsAny   false            hostPath,secret
gce.fluentd-gcp                false          RunAsAny   RunAsAny    RunAsAny   RunAsAny   false            configMap,hostPath,secret
gce.persistent-volume-binder   false          RunAsAny   RunAsAny    RunAsAny   RunAsAny   false            nfs,secret
gce.privileged                 true    *      RunAsAny   RunAsAny    RunAsAny   RunAsAny   false            *
gce.unprivileged-addon         false          RunAsAny   RunAsAny    RunAsAny   RunAsAny   false            emptyDir,configMap,secret

Затем я создаю свои правила PSP и RBAC.

k get psp
NAME                           PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
default-psp                    false          RunAsAny   MustRunAsNonRoot   RunAsAny   RunAsAny   false            *
gce.event-exporter             false          RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            hostPath,secret
gce.fluentd-gcp                false          RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            configMap,hostPath,secret
gce.persistent-volume-binder   false          RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            nfs,secret
gce.privileged                 true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *
gce.unprivileged-addon         false          RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            emptyDir,configMap,secret

Затем я запускаю модуль пользователя root

apiVersion: v1
kind: Pod
metadata:
  name: root-user-pod
spec:
  containers:
  - name: root-user-pod
    image: nginx
    ports:
    - containerPort: 80

И он переходит в состояние выполнения и, глядя на аннотацию, вижу:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubernetes.io/limit-ranger: 'LimitRanger plugin set: cpu request for container
      root-user-pod'
    kubernetes.io/psp: gce.privileged

Очевидно, что мой PSP по умолчанию не используется.

Я пытался отредактировать gce.privileged PSP, но GKE автоматически возвращает его к состоянию по умолчанию privileged.

Затем я создал Pod в определенном пространстве имен как определенный ServiceAccouunt. Мои новые правила RBAC:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-user
  namespace: test
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: test
  name: test-psp-role
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs:     ['use']
  resourceNames:
  - default-psp
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: test-psp-roleBinding
  namespace: test
subjects:
- kind: ServiceAccount
  name: test-user
  namespace: test
roleRef:
  kind: Role
  name: test-psp-role
  apiGroup: rbac.authorization.k8s.io

И я добавляю serviceAccountName: test-user к моему манифесту Pod, а затем развертываю модуль в пространстве имен test, и он тоже переходит в состояние Running.

k get po -n test
NAME            READY   STATUS    RESTARTS   AGE
root-user-pod   1/1     Running   0          7s

С аннотацией:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubernetes.io/psp: gce.privileged
  creationTimestamp: "2019-03-12T15:48:11Z"
  name: root-user-pod
  namespace: test

Так что я не уверен, что делать дальше. Как я могу перевернуть стандартные PSP, которые создает GKE?

Answer 1

TL; DR - привилегированная политика требуется для запуска привилегированных системных модулей, которые обеспечивают критическую функциональность кластера. Ваша учетная запись имеет доступ ко всем политикам PodSecurity.

Использование определенной PodSecurityPolicy может быть разрешено двумя различными способами:

1. Учетная запись службы модуля *1006* имеет разрешение use для определенной PodSecurityPolicy.
2. Создающий пользователь имеет разрешение use на конкретную PodSecurityPolicy.

Вы можете проверить, имеет ли ваша учетная запись доступ к политике, с помощью:

kubectl auth can-i use podsecuritypolicy/${PSP_NAME}

Вы можете проверить, имеет ли учетная запись службы модуля доступ к PSP с помощью:

kubectl --as=system:serviceaccount:${NAMESPACE:-default}:${SERVICE_ACCOUNT:-default} auth can-i use podsecuritypolicy/${PSP_NAME}

Если вы создаете модуль через развертывание, репликацию или какой-либо другой косвенный механизм, то этот модуль создает контроллер, а не пользователь. В этих случаях у контроллера не должно быть доступа к каким-либо привилегированным политикам безопасности модуля, и вы должны увидеть желаемое поведение.

В качестве альтернативы, убедитесь, что пользователи, создающие непривилегированные модули, не имеют доступа к привязке роли администратора кластера.

Известны проблемы с этим подходом, и сообщество Kubernetes работает над их решением до того, как PodSecurityPolicy будет повышен с бета-версии до общедоступной.