Minikube : Restricted PodSecurityPolicy n'est pas restrictif quand on essaie de créer un conteneur privilégié

Question

J'ai activé le podsecuritypolicy dans minikube. Par défaut, il a créé deux psp - privilégié et restreint.

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

J'ai également créé un utilisateur linux - kubexz, pour lequel j'ai créé un ClusterRole et un RoleBinding afin de restreindre la gestion des pods à l'espace de noms de kubexz, et d'utiliser le psp restreint.

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

J'ai placé le fichier kubeconfig dans mon utilisateur kubexz $HOME/.kube. Le RBAC fonctionne bien - à partir de l'utilisateur kubexz, je suis seulement capable de créer et de gérer les ressources des pods dans l'espace de noms kubexz, comme prévu.

Mais quand je poste un manifeste de pods avec securityContext.privileged: true la politique de sécurité des pods restreinte ne m'empêche pas de créer ce pod. Je ne devrais pas être en mesure de créer un pod avec un conteneur à privilèges. Mais le pod est créé. Je ne sais pas ce qui m'échappe.

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

J'ai suivi PodsecurityPolicy en utilisant minikube. Cela ne fonctionne par défaut que si vous utilisez Minikube 1.11.1 avec Kubernetes 1.16.x ou supérieur. .

Note pour les anciennes versions de minikube :

Les anciennes versions de minikube ne sont pas livrées avec le module complémentaire pod-security-policy. Les politiques activées par l'addon doivent donc être appliquées séparément au cluster.

Ce que j'ai fait :

1 . Démarrez minikube avec le contrôleur d'admission PodSecurityPolicy et l'addon pod-security-policy activé.

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

L'addon pod-security-policy doit être activé en même temps que le contrôleur d'admission pour éviter les problèmes lors du démarrage.

2 . Créer utilisateur authentifié :

À cet égard, Kubernetes ne dispose pas d'objets représentant des comptes d'utilisateurs normaux. Les utilisateurs normaux ne peuvent pas être ajoutés à un cluster par le biais d'un appel API.

Même si un utilisateur normal ne peut pas être ajouté via un appel API, tout utilisateur qui présente un certificat valide signé par l'autorité de certification (CA) du cluster est considéré comme authentifié. Dans cette configuration, Kubernetes détermine le nom d'utilisateur à partir du champ du nom commun dans le "sujet" du certificat (par exemple, "/CN=bob"). . À partir de là, le sous-système de contrôle d'accès basé sur les rôles (RBAC) détermine si l'utilisateur est autorisé à effectuer une opération spécifique sur une ressource.

Ici vous trouverez un exemple de la manière dont vous pouvez préparer correctement les certificats clients X509 et configurer le fichier KubeConfig en conséquence.

La partie la plus importante est de définir correctement le nom commun (CN) et le champ de l'organisation (O) :

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

Le nom commun (CN) du sujet sera utilisé comme nom d'utilisateur pour la demande d'authentification. Le champ organisation (O) sera utilisé pour indiquer l'appartenance de l'utilisateur à un groupe.

---

Enfin, j'ai créé votre configuration sur la base de la configuration standard de minikube et je ne parviens pas à recréer votre problème pour les raisons suivantes hostPID: true o securityContext.privileged: true

A considérer :

a ). Vérifiez si votre certificat du client pour l'authentification et kubeconfig ont été créés/réglés correctement, en particulier le nom commun (CN) et le champ organisationnel (O).

b ). Assurez-vous que vous passez d'un contexte à l'autre lorsque vous effectuez des demandes au nom de différents utilisateurs.

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