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.

migration de PodSecurityPolicy

Pour Kubernetes ≥ v1.25. PodSecurityPolicy (PSP) est supprimé. Vous pouvez maintenant utiliser SUSE Security Admission Controller pour le contrôle d’admission sur vos clusters Kubernetes.

Admission Controller a des politiques séparées pour atteindre le même objectif qu’une configuration monolithique de PSP. Chaque définition de politique Admission Controller fonctionne comme une section de configuration différente dans la spécification d’un PSP. La correspondance des champs de configuration de PSP avec leurs politiques Admission Controller respectives se trouve dans le tableau de correspondance ci-dessous.

Avec Admission Controller, les opérateurs ont un contrôle granulaire de la configuration des politiques dans leurs clusters.

Avec une instance de Admission Controller, vous pouvez déployer des politiques pour remplacer l’objet PodSecurityPolicy. Nous considérons ces règles dans cet exemple :

  • une PSP désactivant l’escalade de privilèges

  • conteneurs privilégiés

  • bloquer les pods s’exécutant en tant que root

  • forcer un groupe d’utilisateurs particulier

  • bloquer les espaces de noms d’hôtes

  • permettre à un pod d’utiliser uniquement le port 443

La définition YAML de ce PSP est :

Définition YAML du PSP
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  allowPrivilegeEscalation: false
  runAsUser:
    rule: MustRunAsNonRoot
  supplementalGroups:
    rule: MustRunAs
    ranges:
      - min: 1000
        max: 65535
  privileged: false
  hostNetwork: false
  hostIPC: false
  hostPID: false
  hostPorts:
    - min: 443
      max: 443

Admission Controller remplacements pour le PSP

Nous allons maintenant créer des politiques Admission Controller pour atteindre le même objectif. Vous appliquez chaque règle avec une politique Admission Controller distincte. Ainsi, dans cet exemple, vous avez besoin d’une politique distincte pour l’application de chacun de :

  • l’escalade de privilèges

  • configuration des utilisateurs et des groupes

  • espaces de noms d’hôtes

  • configuration des conteneurs privilégiés.

Bloquer l’escalade de privilèges des conteneurs

Vous pouvez déployer une politique comme indiqué ci-dessous :

commande kubectl pour le déploiement de la politique
$ kubectl apply -f - <<EOF
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-allow-privilege-escalation
spec:
  module: ghcr.io/kubewarden/policies/allow-privilege-escalation-psp:v0.2.6
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - pods
      operations:
        - CREATE
        - UPDATE
  mutating: false
  settings:
    default_allow_privilege_escalation: false
EOF

Dans cette commande, nous avons spécifié default_allow_privilege_escalation pour être false. Cette politique restreint les pods qui tentent de s’exécuter avec plus de privilèges que le conteneur parent.

Sortie de kubectl qui tente d’augmenter les privilèges
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      allowPrivilegeEscalation: true
  - name: sidecar
    image: sidecar
EOF
Error from server: error when creating "STDIN": admission webhook "clusterwide-psp-allow-privilege-escalation.kubewarden.admission" denied the request: one of the containers has privilege escalation enabled

Configuration des utilisateurs et des groupes

Maintenant, pour appliquer la configuration des utilisateurs et des groupes, vous pouvez utiliser la politique user-group-psp-policy.

`kubectl`user-group-psp-policy pour utiliser la politique user-group-psp.
$ kubectl apply -f - <<EOF
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-user-group
spec:
  module: ghcr.io/kubewarden/policies/user-group-psp:v0.4.9
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - pods
      operations:
        - CREATE
        - UPDATE
  mutating: true
  settings:
    run_as_user:
      rule: MustRunAsNonRoot
    supplemental_groups:
      rule: MustRunAs
      ranges:
        - min: 1000
          max: 65535
EOF

Vous devez configurer la politique avec mutation: true. C’est nécessaire car la politique ajoutera supplementalGroups lorsque l’utilisateur ne les définit pas.

Ainsi, maintenant les utilisateurs ne peuvent pas déployer des pods s’exécutant en tant que root :

Exemple de sortie où runAsNonRoot : faux
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      runAsNonRoot: false
      runAsUser: 0
EOF
Error from server: error when creating "STDIN": admission webhook "clusterwide-psp-user-group-fb836.kubewarden.admission" denied the request: RunAsNonRoot should be set to true
Exemple de sortie où runAsUser : 0
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      runAsNonRoot: true
      runAsUser: 0
EOF
Error from server: error when creating "STDIN": admission webhook "clusterwide-psp-user-group-fb836.kubewarden.admission" denied the request: Invalid user ID: cannot run container with root ID (0)

Cet exemple ci-dessous montre l’ajout d’un supplemental group, malgré le fait qu’il ne soit pas défini par nous.

Exemple d’ajout d’un groupe supplémentaire
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
EOF
pod/nginx created
$ kubectl get pods -o json nginx | jq ".spec.securityContext"
{
  "supplementalGroups": [
    10000
  ]
}

Configuration des conteneurs privilégiés

Vous devez remplacer l’ancienne configuration PSP qui bloque les conteneurs privilégiés. Il est nécessaire de déployer la politique https://github.com/kubewarden/pod-privileged-policypod-privileged-policy. Cette politique ne nécessite aucun paramètre. Une fois en cours d’exécution, elle bloquera les pods privilégiés.

Application de la politique pod-privileged-policy
$ kubectl apply -f - <<EOF
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-privileged
spec:
  module: ghcr.io/kubewarden/policies/pod-privileged:v0.2.7
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - pods
      operations:
        - CREATE
        - UPDATE
  mutating: false
  settings: null
EOF

Pour tester la politique, nous pouvons essayer d’exécuter un pod avec la configuration privilégiée activée :

Pod exécuté avec la configuration privilégiée activée
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    securityContext:
      privileged: true
  - name: sleeping-sidecar
    image: alpine
    command: ["sleep", "1h"]
EOF
Error from server: error when creating "STDIN": admission webhook "clusterwide-psp-privileged.kubewarden.admission" denied the request: Privileged container is not allowed

Configuration de l’espace de noms hôte

Pour terminer l’exercice de migration PSP, vous devez désactiver le partage de l’espace de noms hôte. Pour cela, nous allons utiliser la politique https://github.com/kubewarden/host-namespaces-psp-policy`host-namespace-psp`policy`. Il permet à l’administrateur de cluster de bloquer les espaces de noms IPC, PID et réseau individuellement. Il définit également les ports sur lesquels les pods peuvent être ouverts, sur l’adresse IP de l’hôte.

Désactivation du partage d’espace de noms et définition des ports
$ kubectl apply -f - <<EOF
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-hostnamespaces
spec:
  module: ghcr.io/kubewarden/policies/host-namespaces-psp:v0.1.6
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - pods
      operations:
        - CREATE
        - UPDATE
  mutating: false
  settings:
    allow_host_ipc: false
    allow_host_pid: false
    allow_host_ports:
      - min: 443
        max: 443
    allow_host_network: false
EOF

Nous pouvons valider la politique. Le pod ne devrait pas être en mesure de partager les espaces de noms de l’hôte :

Exemple de blocage d’espace de noms
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  hostIPC: true
  hostNetwork: false
  hostPID: false
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  - name: sleeping-sidecar
    image: alpine
    command: ["sleep", "1h"]
EOF

Error from server: error when creating "STDIN": admission webhook "clusterwide-psp-hostnamespaces.kubewarden.admission" denied the request: Pod has IPC enabled, but this is not allowed
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  hostIPC: false
  hostNetwork: true
  hostPID: false
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  - name: sleeping-sidecar
    image: alpine
    command: ["sleep", "1h"]
EOF
Error from server: error when creating "STDIN": admission webhook "clusterwide-psp-hostnamespaces.kubewarden.admission" denied the request: Pod has host network enabled, but this is not allowed
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  hostIPC: false
  hostNetwork: false
  hostPID: true
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  - name: sleeping-sidecar
    image: alpine
    command: ["sleep", "1h"]
EOF
Error from server: error when creating "STDIN": admission webhook "clusterwide-psp-hostnamespaces.kubewarden.admission" denied the request: Pod has host PID enabled, but this is not allowed

Dans cet dernier exemple, le pod ne devrait être capable d’exposer que le port 443. Si d’autres ports sont configurés dans hostPorts, une erreur devrait se produire.

Tentative d’utilisation du port 80 dans hostPorts
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
      - containerPort: 80
        hostPort: 80
  - name: sleeping-sidecar
    image: alpine
    command: ["sleep", "1h"]
EOF
Error from server: error when creating "STDIN": admission webhook "clusterwide-psp-hostnamespaces.kubewarden.admission" denied the request: Pod is using unallowed host ports in containers

Script de migration PSP

L’équipe Admission Controller a développé un script pour la migration PSP. Il utilise l’outil de migration de AppVia. L’outil AppVia lit une configuration PSP au format YAML. Il génère ensuite les politiques correspondantes. Il le fait pour Admission Controller et d’autres moteurs de politique.

L’outil de migration AppVia est hors du contrôle des mainteneurs de Kubewarden. Cela signifie qu’il est possible qu’il génère des politiques Admission Controller obsolètes. À utiliser avec prudence. Nous avons besoin d’une pull request pour AppVia, sur laquelle le travail est en cours. Contactez-nous pour plus d’informations si nécessaire.

Le script est disponible dans le dépôt Admission Controller utils. Il télécharge l’outil de migration AppVia dans le répertoire de travail à utiliser. Il traite les PSP définis dans le contexte par défaut kubectl. Ensuite, il imprime les définitions des politiques Kubewarden sur la sortie standard. Les utilisateurs peuvent rediriger le contenu vers un fichier ou vers kubectl directement.

Ce script ne fonctionne que sur des machines Linux x86_64.

Examinons un exemple. Dans un cluster avec le PSP :

  • bloquer l’accès aux espaces de noms d’hôte :

  • bloquer les conteneurs privilégiés

  • ne pas permettre l’escalade de privilèges

  • supprimer les capacités des conteneurs

  • lister les types de volumes autorisés

  • définir les utilisateurs et groupes autorisés à être utilisés

  • contrôler le groupe supplémentaire appliqué aux volumes

  • forcer les conteneurs à s’exécuter dans un système de fichiers racine en lecture seule

Le YAML suivant pourrait être utilisé.

La configuration du PSP
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  hostNetwork: false
  hostIPC: false
  hostPID: false
  hostPorts:
    - min: 80
      max: 8080
  privileged: false
  # Required to prevent escalations to root.
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  # Allow core volume types.
  volumes:
    - "configMap"
    - "emptyDir"
    - "projected"
    - "secret"
    - "downwardAPI"
    # Assume that ephemeral CSI drivers & persistentVolumes set up by the cluster admin are safe to use.
    - "csi"
    - "persistentVolumeClaim"
    - "ephemeral"
  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
  readOnlyRootFilesystem: true

Admission ControllerLes politiques peuvent être appliquées directement à un cluster en utilisant la commande suivante :

$ ./psp-to-kubewarden | kubectl apply -f -
Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
clusteradmissionpolicy.policies.kubewarden.io/psp-privileged-82bf2 created
clusteradmissionpolicy.policies.kubewarden.io/psp-readonlyrootfilesystem-b4a55 created
clusteradmissionpolicy.policies.kubewarden.io/psp-hostnamespaces-a25a2 created
clusteradmissionpolicy.policies.kubewarden.io/psp-volumes-cee05 created
clusteradmissionpolicy.policies.kubewarden.io/psp-capabilities-34d8e created
clusteradmissionpolicy.policies.kubewarden.io/psp-usergroup-878b0 created
clusteradmissionpolicy.policies.kubewarden.io/psp-fsgroup-3b08e created
clusteradmissionpolicy.policies.kubewarden.io/psp-defaultallowprivilegeescalation-b7e87 created

Si les utilisateurs souhaitent inspecter les stratégies avant de les appliquer, il est possible de rediriger le contenu vers un fichier ou de le consulter directement dans la console

Pour stocker les stratégies générées et les visualiser :

./psp-to-kubewarden > policies.yaml && cat policies.yaml
$ ./psp-to-kubewarden > policies.yaml
$ cat policies.yaml
---
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-privileged-eebb9
spec:
  module: registry://ghcr.io/kubewarden/policies/pod-privileged:v0.2.7
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - pods
      operations:
        - CREATE
        - UPDATE
  mutating: false
  settings: null

---
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-readonlyrootfilesystem-34d7c
spec:
  module: registry://ghcr.io/kubewarden/policies/readonly-root-filesystem-psp:v0.1.6
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - pods
      operations:
        - CREATE
        - UPDATE
  mutating: false
  settings: null

---
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-hostnamespaces-41314
spec:
  module: registry://ghcr.io/kubewarden/policies/host-namespaces-psp:v0.1.6
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - pods
      operations:
        - CREATE
        - UPDATE
  mutating: false
  settings:
    allow_host_ipc: false
    allow_host_pid: false
    allow_host_ports:
      - max: 8080
        min: 80
    allow_host_network: false

---
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-volumes-2fd34
spec:
  module: registry://ghcr.io/kubewarden/policies/volumes-psp:v0.1.11
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - pods
      operations:
        - CREATE
        - UPDATE
  mutating: false
  settings:
    allowedTypes:
      - configMap
      - emptyDir
      - projected
      - secret
      - downwardAPI
      - csi
      - persistentVolumeClaim
      - ephemeral

---
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-capabilities-340fe
spec:
  module: registry://ghcr.io/kubewarden/policies/capabilities-psp:v0.1.13
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - pods
      operations:
        - CREATE
        - UPDATE
  mutating: false
  settings:
    allowed_capabilities: []
    required_drop_capabilities:
      - ALL

---
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-usergroup-19f7a
spec:
  module: registry://ghcr.io/kubewarden/policies/user-group-psp:v0.4.9
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - pods
      operations:
        - CREATE
        - UPDATE
  mutating: false
  settings:
    run_as_user:
      rule: MustRunAsNonRoot
    supplemental_groups:
      ranges:
        - max: 65535
          min: 1
      rule: MustRunAs

---
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-fsgroup-52337
spec:
  module: registry://ghcr.io/kubewarden/policies/allowed-fsgroups-psp:v0.1.10
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - pods
      operations:
        - CREATE
        - UPDATE
  mutating: false
  settings:
    ranges:
      - max: 65535
        min: 1
    rule: MustRunAs

---
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psp-defaultallowprivilegeescalation-6f11b
spec:
  module: registry://ghcr.io/kubewarden/policies/allow-privilege-escalation-psp:v0.2.6
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - pods
      operations:
        - CREATE
        - UPDATE
  mutating: false
  settings:
    default_allow_privilege_escalation: false

Les noms des stratégies sont générés par l’outil de migration PSP. Vous voudrez peut-être changer le nom pour quelque chose de plus significatif.