Pod Security Policy не работает, как задумано - PullRequest
0 голосов
/ 08 марта 2019

Я создаю Политику безопасности Pod, чтобы запретить ВСЕМ пользователям создавать Pod как Root-пользователь. Мой кластер на GKE. Шаги, которые я выполнил до сих пор:

1) Включить PodSecurityPolicy в моем кластере

gcloud beta container clusters update standard-cluster-11  --enable-pod-security-policy

2) Определите политику. Политика проста и ограничивает пользователя root.

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: a-restrict-root
spec:
  privileged: false
  runAsUser:
    rule: MustRunAsNonRoot  # <------ Root user restricted.
  seLinux:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - '*'

3) И, конечно же, реализация правильных правил RBAC, чтобы их можно было применять для ВСЕХ пользователей.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: gce:podsecuritypolicy:a-restrict-root
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
    kubernetes.io/cluster-service: "true"
rules:
- apiGroups:
  - policy
  resourceNames:
  - a-restrict-root
  resources:
  - podsecuritypolicies
  verbs:
  - use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gce:podsecuritypolicy:a-restrict-root
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
    kubernetes.io/cluster-service: "true"
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: gce:podsecuritypolicy:a-restrict-root
subjects:
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:serviceaccounts

Теперь наступает момент, когда я пытаюсь раскрутить стручок. Определение модуля выглядит так:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: gcr.io/google-samples/node-hello:1.0
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

Как видите, runAsUser установлен на 0, что означает root.

Когда я запускаю kubectl create -f pod.yaml, модуль создается и переходит в состояние Running.

Когда я выполняю exec в Pod, я вижу все процессы, выполняющиеся от имени root

$ kubectl exec -it security-context-demo -- sh
# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0   4336   812 ?        Ss   19:25   0:00 /bin/sh -c node server.js
root           6  0.4  0.5 772124 22656 ?        Sl   19:25   0:00 node server.js
root          11  0.0  0.0   4336   724 ?        Ss   19:26   0:00 sh
root          16  0.0  0.0  17500  2072 ?        R+   19:26   0:00 ps aux

Но на основании моего PodSecurityPolicy это НЕ должно быть разрешено. Я что-то пропустил?

ОБНОВЛЕНИЕ:

Я развернул модуль nginx по умолчанию, который, как я знаю, всегда запускается от имени пользователя root. Его манифест:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx

И когда я его создаю, он тоже запускается успешно.

$ kubectl get po
NAME                    READY     STATUS    RESTARTS   AGE
nginx                   1/1       Running   0          2m

Принимая во внимание, что из-за PSP он не должен запускаться.

Ответы [ 2 ]

1 голос
/ 09 марта 2019

Если вы извлекаете созданный модуль из API, он будет содержать аннотацию, указывающую, какой PSP разрешил модуль. Я ожидаю, что другой PSP на месте, что позволяет pod

0 голосов
/ 08 марта 2019

Я получил то, что вам не хватает, просто добавьте это в свой файл конфигурации pod:

Перед этим убедитесь, что create the user (say, appuser) uid -> say, 999 и group (say, appgroup) gid ->say, 999 в контейнере Docker, а затем попробуйте запустить контейнер с этимuser и добавьте:

securityContext:
  runAsUser: 999

Это может быть хорошим чтением: SecurityContext

Кроме того, когда вы делаете это:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Вы переопределяете PodSecurityPolicy см. здесь

Обновление: 1

Как это исправить:

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: a-restrict-root
spec:
  privileged: false
  defautlAllowPrivilegeEscalation: false
  # This is redundant with non-root + disallow privilege escalation,
  # but we can provide it for defense in depth.
  requiredDropCapabilities:
    - ALL
  hostIPC: false
  hostPID: false
  runAsUser:
    # Require the container to run without root privileges.
    rule: 'MustRunAsNonRoot'
  seLinux:
    # This policy assumes the nodes are using AppArmor rather than SELinux.
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...