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.

Tests pour les auteurs de stratégies

Les stratégies SUSE Security Admission Controller sont des programmes réguliers compilés en WebAssembly (Wasm). Comme pour tout type de programme, une bonne couverture de tests est importante.

Les auteurs de stratégies peuvent utiliser leurs environnements de développement préférés. Vous pouvez utiliser des outils familiers et des frameworks de test pour vérifier le développement.

Ces stratégies Admission Controller sont des exemples écrits en Rust et Go :

Ils ont des suites de tests utilisant des tests standards pour leurs environnements de développement.

Les stratégies utilisent GitHub Actions pour leurs pipelines CI.

Tests de bout en bout

Vous pouvez également écrire des tests qui s’exécutent contre le binaire Wasm contenant votre stratégie. Pour ce faire sans avoir à déployer un cluster Kubernetes, vous pouvez utiliser ces outils :

  • bats : est utilisé pour écrire des tests et automatiser leur exécution.

  • kwctl : l’outil CLI par défaut de Admission Controller qui vous aide avec les opérations liées aux stratégies ; tirer, inspecter, annoter, pousser et exécuter.

Pour utiliser kwctl run, vous avez besoin des éléments suivants :

  1. La référence du fichier binaire Wasm de la stratégie à exécuter. La stratégie Admission Controller peut être chargée depuis :

    • le système de fichiers local (file://)

    • un serveur HTTP(s) (https://

    • un registre OCI (registry://).

  2. L’objet de demande d’admission à tester. Vous le fournissez via l’argument --request-path, ou sur stdin en définissant --request-path à -.

  3. 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.

Voici comment utiliser kwctl pour tester le binaire Wasm de la ingress-policy mentionnée précédemment :

$ curl https://raw.githubusercontent.com/kubewarden/ingress-policy/v0.1.8/test_data/ingress-wildcard.json 2> /dev/null | \
    kwctl run \
        --settings-json '{"allowPorts": [80], "denyPorts": [3000]}' \
        --request-path - \
        registry://ghcr.io/kubewarden/policies/ingress:v0.1.8 | jq

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

En utilisant bats, vous pouvez écrire un test qui exécute cette commande et recherche les sorties attendues :

Un test bats 
@test "all is good" {
  run kwctl run \
    --request-path test_data/ingress-wildcard.json \
    --settings-json '{"allowPorts": [80], "denyPorts": [3000]}' \
    ingress-policy.wasm

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

  # settings validation passed
  [[ "$output" == *"valid: true"* ]]

  # request accepted
  [[ "$output" == *"allowed: true"* ]]
}

Vous pouvez mettre le code dans un fichier, e2e.bats, par exemple, puis invoquer bats en :

$ bats e2e.bats
 ✓ all is good

1 tests, 0 failures

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