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.

Erstellen einer neuen Validierungsrichtlinie

Dieses Tutorial behandelt die Erstellung einer Richtlinie, die die Labels von Pod-Objekten validiert.

Die Richtlinie soll alle Pods ablehnen, die eines oder mehrere Labels auf der Sperrliste verwenden. Die Richtlinie validiert auch bestimmte Labels mithilfe eines vom Benutzer bereitgestellten regulären Ausdrucks.

Zusammenfassend sollten die Richtlinieinstellungen wie folgt aussehen:

# List of labels that cannot be used
denied_labels:
- foo
- bar

# Labels that are validated with user-defined regular expressions
constrained_labels:
  priority: "[123]"
  cost-center: "^cc-\d+"

Die Richtlinie lehnt die Erstellung dieses Pods ab:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    foo: hello world
spec:
  containers:
    - name: nginx
      image: nginx:latest

Sie lehnt auch die Erstellung dieses Pods ab:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    cost-center: cc-marketing
spec:
  containers:
    - name: nginx
      image: nginx:latest

Sie können die Einstellungen der Richtlinie verwenden, um die Verwendung einer Labelspezifikation zu erzwingen, unabhängig vom Inhalt:

constrained_labels:
  mandatory-label: ".*" # <- this label must be present, we don't care about its value

Erstellen des Grundgerüsts für ein neues Richtlinienprojekt

Sie können ein neues Richtlinienprojekt mit dem Vorlagen-Repository erstellen. Wählen Sie die grüne Schaltfläche "Diese Vorlage verwenden" oben auf der Seite und folgen Sie dem Assistenten von GitHub.

Klonen Sie das Repository lokal und setzen Sie die module-Direktive in der go.mod-Datei so, dass sie wie folgt aussieht:

module <path to your repository>

Eine echte Richtlinie würde einen Repository-Pfad verwenden, wie github.com/kubewarden/go-policy-template.

Tester

Vorausgesetzt, die erforderlichen Werkzeuge sind vorhanden, verwendet ein make test-Befehl Docker, um ein TinyGo-Compiler-Image herunterzuladen, um die Richtlinienvorlage zu erstellen und zu testen.

Der Standard-make-Befehl erstellt das policy.wasm-Ziel. Dann führt make test die definierten Go-Tests aus. Der Befehl make e2e-tests führt Tests mit bats innerhalb eines Admission Controller-Clusters aus. Nach dem Klonen der go-policy-template überprüfen diese Befehle, ob Sie über die erforderlichen Werkzeuge für das Tutorial verfügen.

Ausgabe der make-Befehle

make test
docker run \
        --rm \
        -e GOFLAGS="-buildvcs=false" \
        -v /home/jhk/projects/suse/tmp/go-kw-demo:/src \
        -w /src tinygo/tinygo:0.30.0 \
        tinygo build -o policy.wasm -target=wasi -no-debug .
Unable to find image 'tinygo/tinygo:0.30.0' locally
0.30.0: Pulling from tinygo/tinygo
9aaefb8797c4: Pull complete
24ab7ca26e01: Pull complete
ca4ea8be6361: Pull complete
50380d0859d2: Pull complete
4f4fb700ef54: Pull complete
ea0ddd497f04: Pull complete
01ba28116afb: Pull complete
Digest: sha256:5cbf5e50aec3a00fcff8bb4ae070a07eea8198187a97b21dff6d873d2274ce7a
Status: Downloaded newer image for tinygo/tinygo:0.30.0
go test -v
=== RUN   TestParsingSettingsWithNoValueProvided
--- PASS: TestParsingSettingsWithNoValueProvided (0.00s)
=== RUN   TestIsNameDenied
--- PASS: TestIsNameDenied (0.00s)
=== RUN   TestEmptySettingsLeadsToApproval
NATIVE: |{"level":"debug","message":"validating pod object","name":"test-pod","namespace":"default"}
|
--- PASS: TestEmptySettingsLeadsToApproval (0.00s)
=== RUN   TestApproval
NATIVE: |{"level":"debug","message":"validating pod object","name":"test-pod","namespace":"default"}
|
--- PASS: TestApproval (0.00s)
=== RUN   TestApproveFixture
NATIVE: |{"level":"debug","message":"validating pod object","name":"test-pod","namespace":"default"}
|
--- PASS: TestApproveFixture (0.00s)
=== RUN   TestRejectionBecauseNameIsDenied
NATIVE: |{"level":"debug","message":"validating pod object","name":"test-pod","namespace":"default"}
|
NATIVE: |{"level":"info","message":"rejecting pod object","name":"test-pod","denied_names":"foo,test-pod"}
|
--- PASS: TestRejectionBecauseNameIsDenied (0.00s)
PASS
ok      github.com/kubewarden/go-policy-template        0.004s

und

make e2e-tests
bats e2e.bats
e2e.bats
 ✓ reject because name is on deny list
 ✓ accept because name is not on the deny list
 ✓ accept because the deny list is empty

3 tests, 0 failures