Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Il s'agit d'une documentation non publiée pour Admission Controller 1.34-dev.

Stratégies de mutation

Les stratégies de mutation reçoivent une demande d’objet et la reconstruisent (la modifient) en une nouvelle demande. Cela est conforme aux valeurs définies dans les paramètres de la stratégie. La demande passe par l’API Kubernetes, pouvant être évaluée par d’autres stratégies.

Pour permettre un comportement de demande de mutation, définissez le champ ClusterAdmissionPolicy.mutating sur true.

Cependant, si vous définissez le champ ClusterAdmissionPolicy.mutating sur false, les demandes modifiées seront rejetées.

Pourquoi les stratégies de mutation peuvent être dangereuses

Des stratégies de mutation non examinées peuvent introduire des vulnérabilités

Pour prévenir les abus du système, les administrateurs SUSE Security Admission Controller devraient examiner les stratégies de mutation. Les stratégies de mutation pourraient, par exemple, modifier une charge de travail, de sorte qu’elle permette la création de conteneurs privilégiés.

Solution

En cas de doute, séparez les stratégies en stratégies de mutation et de validation, au lieu d’écrire ou de déployer des stratégies qui valident et mutent à la fois. Ceci est particulièrement important lors de l’utilisation d’un DSL (tel que Rego) pour construire des stratégies complexes.

Des stratégies de mutation mal configurées, associées à des contrôleurs Kubernetes tiers, peuvent se retrouver bloquées dans une boucle infinie

Les stratégies de mutation renvoient des demandes qui passent par l’API Kubernetes. S’il y a d’autres contrôleurs Kubernetes qui écoutent ces mêmes ressources, ils peuvent les modifier à nouveau dans une demande de suivi. Cela pourrait conduire à une boucle de rétroaction infinie de mutations.

Solution

Effectuez la mutation contre :

Le type de ressource le plus bas (par exemple : Pod).
Le type de ressource le plus élevé (par exemple : Déploiement). Remarque : cela pourrait toujours entraîner des boucles si un contrôleur gère ces ressources. Par exemple, les contrôleurs des solutions GitOps (comme fleet, flux, argo, …) ou d’autres contrôleurs tiers qui traduisent leurs propres CRDs en objets de déploiement.

Exemples

Vous pouvez voir une stratégie de mutation en action. Créez le suivant ClusterAdmissionPolicy avec le champ mutating défini sur true :

# Command
kubectl apply -f - <<EOF
apiVersion: policies.kubewarden.io/v1alpha2
kind: ClusterAdmissionPolicy
metadata:
  name: psp-user-group
spec:
  module: "registry://ghcr.io/kubewarden/policies/user-group-psp:v0.1.5"
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations:
    - CREATE
    - UPDATE
  mutating: true
  settings:
    run_as_user:
      rule: "MustRunAs"
      ranges:
        - min: 1000
          max: 2000
        - min: 3000
          max: 4000
    run_as_group:
      rule: "RunAsAny"
    supplemental_groups:
      rule: "RunAsAny"
EOF

# Output
clusteradmissionpolicy.policies.kubewarden.io/psp-user-group created

Vous utilisez la stratégie psp-user-group pour contrôler les utilisateurs et les groupes dans les conteneurs et pouvez modifier les demandes. Dans l’exemple précédent, vous définissez le champ runAsUser et il est ajouté à la section du conteneur securityContext.

Comme le champ mutating est true, la demande suivante réussit :

# Command
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: pause-user-group
spec:
  containers:
    - name: pause
      image: registry.k8s.io/pause
EOF

# Output
pod/pause-user-group created

Vous pouvez voir les résultats du securityContext du conteneur :

# Command
kubectl get pods pause-user-group -o jsonpath='{ .spec.containers[].securityContext }'

# Output
{"runAsUser":1000}

Maintenant, modifiez le ClusterAdmissionPolicy en définissant le champ mutating sur false :

# Command
kubectl apply -f - <<EOF
apiVersion: policies.kubewarden.io/v1alpha2
kind: ClusterAdmissionPolicy
metadata:
  name: psp-user-group
spec:
  module: "registry://ghcr.io/kubewarden/policies/user-group-psp:v0.1.5"
  rules:
  - apiGroups: [""]
    apiVersions: ["v1"]
    resources: ["pods"]
    operations:
    - CREATE
    - UPDATE
  mutating: false
  settings:
    run_as_user:
      rule: "MustRunAs"
      ranges:
        - min: 1000
          max: 2000
        - min: 3000
          max: 4000
    run_as_group:
      rule: "RunAsAny"
    supplemental_groups:
      rule: "RunAsAny"
EOF

# Output
clusteradmissionpolicy.policies.kubewarden.io/psp-user-group configured

Comme le champ mutating est false, la demande suivante échoue :

# Command
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: pause-user-group
spec:
  containers:
    - name: pause
      image: registry.k8s.io/pause
EOF

# Output
Error from server: error when creating ".\\pause-user-group.yaml": admission webhook "psp-user-group.kubewarden.admission" denied the request: Request rejected by policy psp-user-group. The policy attempted to mutate the request, but it is currently configured to not allow mutations.

En conclusion, vous pouvez voir que Admission Controller reproduit le même comportement que les politiques de sécurité des pods Kubernetes (PSP) dont la prise en charge a cessé.