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.

Test des opérateurs de cluster

En tant qu’opérateur de cluster Kubernetes, vous souhaiterez effectuer des tests pour les stratégies SUSE Security Admission Controller que vous souhaitez utiliser.

Vous aurez des questions comme :

Quels sont les paramètres de stratégie corrects pour obtenir le résultat de validation/mutation nécessaire ?
Comment puis-je être sûr que tout continue à fonctionner comme prévu lorsque je :
- Mettez à niveau la stratégie vers une version plus récente ?
- Ajoutez/modifiez des ressources Kubernetes ?
- Modifiez les paramètres de configuration de la stratégie ?
- et ainsi de suite ?

Admission Controller dispose d’un utilitaire, kwctl, qui permet de tester les stratégies en dehors de Kubernetes.

Pour utiliser kwctl, vous l’invoquez avec les entrées suivantes :

Un URI de fichier binaire WebAssembly de la stratégie à exécuter. La stratégie Admission Controller peut charger depuis le :
- système de fichiers local file://
- un serveur HTTP(s) https://
- un registre OCI registry://.
L’objet de demande d’admission à tester. Vous le fournissez avec l’argument --request-path. Utilisez stdin en définissant --request-path sur -.
Les paramètres de stratégie pour le composant d’exécution sous forme de JSON en ligne via le drapeau --settings-json. Ou un JSON, ou un fichier YAML, chargé depuis le système de fichiers via --settings-path.

Après le test kwctl, imprime l’objet ValidationResponse sur la sortie standard.

Vous pouvez télécharger des binaires précompilés de kwctl ici.

Un exemple de test

Cette section décrit comment tester la psp-apparmor stratégie avec différentes configurations et objets de demande de validation.

Créer des demandes `AdmissionReview`

Vous devez créer des fichiers contenant les objets AdmissionReview pour tester la stratégie.

Vous pouvez créer un fichier nommé pod-req-no-specific-apparmor-profile.json avec le contenu suivant :

pod-req-no-specific-apparmor-profile.json

{
  "uid": "1299d386-525b-4032-98ae-1949f69f9cfc",
  "kind": {
    "kind": "Pod",
    "version": "v1"
  },
  "object": {
    "metadata": {
      "name": "no-apparmor"
    },
    "spec": {
      "containers": [
        {
          "image": "nginx",
          "name": "nginx"
        }
      ]
    }
  },
  "operation": "CREATE",
  "requestKind": {"version": "v1", "kind": "Pod"},
  "userInfo": {
    "username": "alice",
    "uid": "alice-uid",
    "groups": ["system:authenticated"]
  }
}

Cette demande essaie de créer un Pod qui ne spécifie aucun profil AppArmor à utiliser. C’est parce qu’il n’a pas de annotation avec la clé container.apparmor.security.beta.kubernetes.io/<container-name>.

Vous pouvez créer un fichier nommé pod-req-apparmor-unconfined.json avec le contenu suivant :

pod-req-apparmor-unconfined.json

{
  "uid": "1299d386-525b-4032-98ae-1949f69f9cfc",
  "kind": {
    "kind": "Pod",
    "version": "v1"
  },
  "object": {
    "metadata": {
      "name": "privileged-pod",
      "annotations": {
        "container.apparmor.security.beta.kubernetes.io/nginx": "unconfined"
      }
    },
    "spec": {
      "containers": [
        {
          "image": "nginx",
          "name": "nginx"
        }
      ]
    }
  },
  "operation": "CREATE",
  "requestKind": {"version": "v1", "kind": "Pod"},
  "userInfo": {
    "username": "alice",
    "uid": "alice-uid",
    "groups": ["system:authenticated"]
  }
}

Cette demande essaie de créer un Pod avec un conteneur appelé nginx fonctionnant avec le profil AppArmor unconfined. C’est uniquement à des fins de tutoriel. Exécuter en mode unconfined est une mauvaise pratique de sécurité.

Vous pouvez maintenant créer un fichier nommé pod-req-apparmor-custom.json avec le contenu suivant :

pod-req-apparmor-custom.json

{
  "uid": "1299d386-525b-4032-98ae-1949f69f9cfc",
  "kind": {
    "kind": "Pod",
    "version": "v1"
  },
  "object": {
    "metadata": {
      "name": "privileged-pod",
      "annotations": {
        "container.apparmor.security.beta.kubernetes.io/nginx": "localhost/nginx-custom"
      }
    },
    "spec": {
      "containers": [
        {
          "image": "nginx",
          "name": "nginx"
        }
      ]
    }
  },
  "operation": "CREATE",
  "requestKind": {"version": "v1", "kind": "Pod"},
  "userInfo": {
    "username": "alice",
    "uid": "alice-uid",
    "groups": ["system:authenticated"]
  }
}

Ce sont tous des objets AdmissionReview simplifiés. Seuls les champs pertinents pour notre test de la stratégie sont utilisés.

Testez la stratégie

Vous pouvez maintenant utiliser kwctl pour tester la création d’un Pod sans spécifier de profil AppArmor :

$ kwctl run \
    --request-path pod-req-no-specific-apparmor-profile.json \
    registry://ghcr.io/kubewarden/policies/psp-apparmor:v0.1.4 \
    | jq

La stratégie accepte la demande et produit une sortie comme :

{
  "uid": "1299d386-525b-4032-98ae-1949f69f9cfc",
  "allowed": true
}

La stratégie rejette la création d’un Pod avec un profil AppArmor unconfined :

$ kwctl run \
    --request-path pod-req-apparmor-unconfined.json \
    registry://ghcr.io/kubewarden/policies/psp-apparmor:v0.1.4 \
    | jq
{
  "uid": "1299d386-525b-4032-98ae-1949f69f9cfc",
  "allowed": false,
  "status": {
    "message": "These AppArmor profiles are not allowed: [\"unconfined\"]"
  }
}

Lors des deux occasions, vous avez exécuté la stratégie sans fournir le moindre paramètre. Comme le document de la stratégie l’indique, cela empêche l’utilisation de profils non par défaut.

Le Pod utilisant un profil nginx personnalisé est également rejeté par la stratégie :

$ kwctl run \
    --request-path pod-req-apparmor-custom.json \
    registry://ghcr.io/kubewarden/policies/psp-apparmor:v0.1.4 \
    | jq
{
  "uid": "1299d386-525b-4032-98ae-1949f69f9cfc",
  "allowed": false,
  "status": {
    "message": "These AppArmor profiles are not allowed: [\"localhost/nginx-custom\"]"
  }
}

Vous pouvez changer le comportement par défaut, permettant l’utilisation de profils AppArmor choisis :

$ kwctl run \
    --request-path pod-req-apparmor-custom.json \
    --settings-json '{"allowed_profiles": ["runtime/default", "localhost/nginx-custom"]}' \
    registry://ghcr.io/kubewarden/policies/psp-apparmor:v0.1.4 \
    | jq

Maintenant, la demande réussit :

{
  "uid": "1299d386-525b-4032-98ae-1949f69f9cfc",
  "allowed": true
}

Automatisation

Vous pouvez automatiser toutes ces étapes en utilisant bats.

Vous pouvez écrire une série de tests et intégrer leur exécution dans vos pipelines CI et CD existants.

Les commandes peuvent être « enveloppées » dans un test bats :

Un test bats

@test "all is good" {
  run kwctl run \
    --request-path pod-req-no-specific-apparmor-profile.json \
    registry://ghcr.io/kubewarden/policies/psp-apparmor:v0.1.4

  # this prints the output when one the checks below fails
  echo "output = ${output}"

  # request accepted
  [ $(expr "$output" : '.*"allowed":true.*') -ne 0 ]
}

@test "reject" {
  run kwctl run \
    --request-path pod-req-apparmor-custom.json \
    registry://ghcr.io/kubewarden/policies/psp-apparmor:v0.1.4

  # this prints the output when one the checks below fails
  echo "output = ${output}"

  # request rejected
  [ $(expr "$output" : '.*"allowed":false.*') -ne 0 ]
}

Si le code bats est dans le fichier e2e.bats, vous pouvez exécuter le test comme suit :

$ bats e2e.bats
 ✓ all is good
 ✓ reject

2 tests, 0 failures

Cette section contient plus d’informations sur l’écriture de tests de bout en bout pour vos stratégies.

Test des opérateurs de cluster

Un exemple de test

Créer des demandes AdmissionReview

Testez la stratégie

Automatisation

Créer des demandes `AdmissionReview`