Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

Dies ist eine unveröffentlichte Dokumentation für Admission Controller 1.34-dev.

Testen für Richtlinienautoren

SUSE Security Admission Controller Richtlinien sind reguläre Programme, die als WebAssembly (Wasm) kompiliert werden. Wie bei jeder Art von Programm ist eine gute Testabdeckung wichtig.

Richtlinienautoren können ihre bevorzugten Entwicklungsumgebungen verwenden. Sie können vertraute Werkzeuge und Testframeworks verwenden, um die Entwicklung zu überprüfen.

Diese Admission Controller Richtlinien sind Beispiele, die in Rust und Go geschrieben sind:

Sie haben Testsuiten, die Standardtests für ihre Entwicklungsumgebungen verwenden.

Die Richtlinien verwenden GitHub Actions für ihre CI-Pipelines.

End-to-End-Tests

Sie können auch Tests schreiben, die gegen die Wasm-Binärdatei ausgeführt werden, die Ihre Richtlinie enthält. Um dies zu tun, ohne einen Kubernetes-Cluster bereitstellen zu müssen, können Sie diese Werkzeuge verwenden:

  • bats: ist dazu da, Tests zu schreiben und deren Ausführung zu automatisieren.

  • kwctl: Admission Controller’s Standard-Kommandozeilenschnittstelle, die Ihnen bei richtlinienbezogenen Operationen hilft; pull, inspect, annotate, push und run.

Um kwctl run zu verwenden, benötigen Sie Folgendes:

  1. Die Wasm-Binärdatei-Referenz der auszuführenden Richtlinie. Die Admission Controller-Richtlinie kann geladen werden von:

    • dem lokalen Dateisystem (file://)

    • einem HTTP(s)-Server (https://)

    • einer OCI-Registry (registry://).

  2. Das Zulassungsanfrageobjekt zum Testen. Sie geben es über das --request-path-Argument an, oder auf stdin, indem Sie --request-path auf - setzen.

  3. Die Richtlinieneinstellungen für die Laufzeit als Inline-JSON über das --settings-json-Flag. Oder eine JSON- oder YAML-Datei, die vom Dateisystem über --settings-path geladen wird.

Nach dem Test kwctl wird das ValidationResponse-Objekt auf der Standardausgabe ausgegeben.

So verwenden Sie kwctl, um die Wasm-Binärdatei der zuvor erwähnten ingress-policy zu testen:

$ 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

Sie können vorgefertigte Binärdateien von kwctl hier herunterladen.

Mit bats können Sie einen Test schreiben, der diesen Befehl ausführt und nach den erwarteten Ausgaben sucht:

Ein Bats-Test 
@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"* ]]
}

Sie können den Code zum Beispiel in eine Datei, e2e.bats, einfügen und dann bats wie folgt aufrufen:

$ bats e2e.bats
 ✓ all is good

1 tests, 0 failures

Dieser Abschnitt der Dokumentation enthält weitere Informationen zum Schreiben von End-to-End-Tests Ihrer Richtlinien.