Minikube: Restricted PodSecurityPolicy не ограничивает при попытке создать привилегированный контейнер

Question

Я включил podsecuritypolicy в minikube. По умолчанию он создал два psp - привилегированный и ограниченный.

NAME         PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
privileged   true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *
restricted   false          RunAsAny   MustRunAsNonRoot   MustRunAs   MustRunAs   false            configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim

Я также создал пользователя linux - kubexz, для которого я создал ClusterRole и RoleBinding, чтобы ограничить управление только модулями в пространстве имен kubexz и использовать ограниченный psp.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: only-edit
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create", "delete", "deletecollection", "patch", "update", "get", "list", "watch"]
- apiGroups: ["policy"]
  resources: ["podsecuritypolicies"]
  resourceNames: ["restricted"]
  verbs: ["use"]

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: kubexz-rolebinding
  namespace: kubexz
subjects:
   - kind: User
     name: kubexz
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: only-edit

Я установил файл kubeconfig в моем пользователе kubexz $HOME/.kube. RBAC работает нормально - от пользователя kubexz я могу создавать и управлять ресурсами модуля только в пространстве имен kubexz, как и ожидалось.

Но когда я публикую манифест стручка с securityContext.privileged: true, ограниченная политика podsecuritypolicy не мешает мне создать этот модуль. Я не смогу создать модуль с контейнером привилегий. Но стручок создается. Не уверен, что мне не хватает

apiVersion: v1
kind: Pod
metadata:
  name: new-pod
spec:
  hostPID: true
  containers:
  - name: justsleep
    image: alpine
    command: ["/bin/sleep", "999999"]
    securityContext:
      privileged: true

Answer 1

Я следил за PodsecurityPolicy с помощью minikube. По умолчанию это работает только при использовании Minikube 1.11.1 с Kubernetes 1.16.x или выше.

Примечание для старых версий minikube:

Более старые версии minikube не поставляются с надстройкой pod-security-policy, поэтому политики, которые активирует надстройка, должны применяться к кластеру отдельно.

Что я сделал:

1. Запустите minikube с включенным контроллером доступа PodSecurityPolicy и надстройкой pod-security-policy.

minikube start --extra-config=apiserver.enable-admission-plugins=PodSecurityPolicy --addons=pod-security-policy

Надстройка pod-security-policy должна быть включена вместе с контроллером допуска, чтобы предотвратить проблемы во время начальной загрузки.

2. Создать аутентифицированного пользователя:

В связи с этим в Kubernetes нет объектов, представляющих обычные учетные записи пользователей. Обычных пользователей нельзя добавить в кластер с помощью вызова API.

Хотя обычный пользователь не может быть добавлен через вызов API, но любой пользователь, который представляет действительный сертификат, подписанный центром сертификации (CA) кластера, считается аутентифицированным. В этой конфигурации Kubernetes определяет имя пользователя из поля общего имени в "теме" сертификата (например, "/CN=bob"). Отсюда подсистема управления доступом на основе ролей (RBAC) будет определять, авторизован ли пользователь для выполнения определенной операции над ресурсом.

Здесь вы можете найти пример того, как правильно подготовить клиентские сертификаты X509 и соответствующим образом настроить файл KubeConfig.

Самая важная часть - правильно определить общее имя (CN) и поле организации (O):

openssl req -new -key DevUser.key -out DevUser.csr -subj "/CN=DevUser/O=development"

Общее имя (CN) субъекта будет использоваться в качестве имени пользователя для запроса аутентификации. Поле организации (O) будет использоваться для обозначения членства пользователя в группе.

---

Наконец, я создал вашу конфигурацию на основе стандартной настройки minikube и не могу воссоздать вашу проблему из-за hostPID: true или securityContext.privileged: true

Рассматривать:

а). Убедитесь, что ваш клиентский сертификат для аутентификации и файл kubeconfig были созданы / настроены правильно, особенно общее имя (CN) и поле организации (O).

б). Убедитесь, что вы переключаетесь между правильным контекстом при выполнении запросов от имени разных пользователей.

   f.e. kubectl get pods --context=NewUser-context