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.

Richtliniengruppen

Die Funktion der Richtliniengruppe ermöglicht es Benutzern, komplexe Richtlinien zu erstellen, indem sie einfachere kombinieren. Es werden zwei neue benutzerdefinierte Ressourcenbeschreibungen (CRDs) eingeführt:

  • AdmissionPolicyGroup: für Zulassungsrichtlinien, die auf bestimmte Namespaces angewendet werden.

  • ClusterAdmissionPolicyGroup: für Zulassungsrichtlinien, die im gesamten Cluster gelten.

Diese Richtliniengruppen ermöglichen es Benutzern, vorhandene Richtlinien zu verwenden, wodurch der Bedarf an der Erstellung benutzerdefinierter Richtlinien verringert und die Wiederverwendbarkeit erhöht wird. Durch die Vermeidung von Duplizierung der Richtlinienlogik können Benutzer das Management vereinfachen und benutzerdefinierte Richtlinien mit einer DSL-ähnlichen Konfiguration erstellen.

Richtliniengruppen ermöglichen die kombinierte Bewertung mehrerer Richtlinien unter Verwendung logischer Operatoren. Dies erlaubt die Definition komplexer Logik. Allerdings können gewöhnliche Richtlinien Mutationslogik enthalten, um Ressourcen während der Zulassung zu ändern, während Richtliniengruppen nur validieren.

Die Konfiguration für Richtliniengruppen ist ähnlich wie die von gewöhnlichen Richtlinien. Der Unterschied besteht in der Hinzufügung der Felder expression, message und policies sowie der Deklaration kontextabhängiger Regeln an einem anderen Ort.

Dies ist ein Beispiel für ein ClusterAdmissionPolicyGroup, das Sie in den nächsten Abschnitten verwenden können, um die verschiedenen Felder zu erklären:

Ein ClusterAdmissionPolicyGroup, das Pods ablehnt, die Bilder mit dem latest-Tag verwenden, es sei denn, die Bilder sind von zwei vertrauenswürdigen Parteien signiert: Alice und Bob. 
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicyGroup # or AdmissionPolicyGroup
metadata:
  name: demo
spec:
  rules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["pods"]
      operations:
        - CREATE
        - UPDATE
  policies:
    signed_by_alice:
      module: ghcr.io/kubewarden/policies/verify-image-signatures:v0.3.0
      settings:
        modifyImagesWithDigest: false
        signatures:
          - image: "*"
            pubKeys:
              - |
                -----BEGIN PUBLIC KEY-----
                MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEyg65hiNHt8FXTamzCn34IE3qMGcV
                yQz3gPlhoKq3yqa1GIofcgLjUZtcKlUSVAU2/S5gXqyDnsW6466Jx/ZVlg==
                -----END PUBLIC KEY-----
    signed_by_bob:
      module: ghcr.io/kubewarden/policies/verify-image-signatures:v0.3.0
      settings:
        modifyImagesWithDigest: false
        signatures:
          - image: "*"
            pubKeys:
              - |
                -----BEGIN PUBLIC KEY-----
                MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEswA3Ec4w1ErOpeLPfCdkrh8jvk3X
                urm8ZrXi4S3an70k8bf1OlGnI/aHCcGleewHbBk1iByySMwr8BabchXGSg==
                -----END PUBLIC KEY-----
    reject_latest:
      module: registry://ghcr.io/kubewarden/policies/trusted-repos:v0.2.0
      settings:
        tags:
          reject:
            - latest
  expression: "reject_latest() || (signed_by_alice() && signed_by_bob())"
  message: "the image is using the latest tag or is not signed by Alice and Bob"

Hauptkonfigurationsfelder

Dieser Abschnitt behandelt die Hauptkonfigurationsfelder einer Richtliniengruppe.

Das Attribut policies

Das Feld für Richtlinien ist eine Zuordnung gewöhnlicher Richtlinien. SUSE Security Admission Controller ruft Richtlinien durch die Richtliniengruppe auf, um zu bestimmen, ob die Ressource, die bewertet wird, akzeptiert oder abgelehnt wird. Die Definitionen dieser Richtlinien sind eine vereinfachte Version von gewöhnlichen Admission Controller Richtlinien, die nur die Attribute module, settings und contextAwareResources enthalten. Diese Elemente sind notwendig, damit die Richtlinien innerhalb einer Richtliniengruppe funktionieren.

Ein einzigartiger Name identifiziert jede Richtlinie der Richtliniengruppe. Zum Beispiel definiert der folgende Ausschnitt drei Richtlinien: signed_by_alice, signed_by_bob und reject_latest_tag.

policies:
  signed_by_alice:
    module: ghcr.io/kubewarden/policies/verify-image-signatures:v0.2.8
    settings: {} # settings for the policy
  signed_by_bob:
    module: ghcr.io/kubewarden/policies/verify-image-signatures:v0.2.8
    settings: {} # settings for the policy
  reject_latest_tag:
    module: ghcr.io/kubewarden/policies/trusted-repos-policy:v0.2.0
    settings: {} # settings for the policy

Eine Richtliniengruppe kann dieselbe Richtlinie mehrfach mit unterschiedlichen Einstellungen enthalten.

Das Attribut expression

Das expression Attribut enthält eine Aussage, die aus den Richtlinienidentifikatoren besteht, die durch logische Operatoren verbunden sind.

Die Auswertung der expression Aussage muss zu einem booleschen Wert führen.

Die Darstellung der Richtlinien erfolgt als Funktion, die nach dem im .spec.policies Map angegebenen Identifikator benannt ist. Die Ergebnisse, die durch die Auswertung der Richtlinien erzeugt werden, werden dann unter Verwendung der vom Benutzer bereitgestellten logischen Operatoren ausgewertet.

Dies sind die unterstützten Operatoren:

  • &&: wird verwendet, um AND Operationen durchzuführen.

  • ||: wird verwendet, um OR Operationen durchzuführen.

  • !: wird verwendet, um NOT Operationen durchzuführen.

Sie können runde Klammern ( ) verwenden, um die Auswertungsprioritäten zu definieren.

Zum Beispiel, bei dem folgenden Ausdruck:

reject_latest() || (signed_by_alice() && signed_by_bob())

Die Richtlinie lehnt Arbeitslasten ab, die Bilder mit dem latest-Tag verwenden, es sei denn, sowohl Alice als auch Bob haben die Bilder signiert.

Das message Attribut und das Antwortformat

Das message Feld gibt die Nachricht an, die zurückgegeben wird, wenn die Auswertung der expression zu einer Ablehnung führt. Die Antwort enthält die Nachricht zusammen mit den Ergebnissen der individuellen Richtlinenauswertung.

Die Auswertung von Richtlinien, die zur Gruppe gehören, erfolgt nur, wenn es notwendig ist.

Zum Beispiel, bei dem folgenden Ausdruck:

reject_latest() || (signed_by_alice() && signed_by_bob())

Die signed_by_bob und signed_by_alice Richtlinien werden nicht ausgewertet, wenn die reject_latest Richtlinie true zurückgibt.

In ähnlicher Weise wird die signed_by_bob Richtlinie nicht ausgewertet, wenn die signed_by_alice und die reject_latest Richtlinien false zurückgeben.

Dies vermeidet unnötige Auswertungen von Richtlinien in der Gruppe und ermöglicht schnelle Antworten auf die Zulassungsanfragen.

Das System sendet alle Bewertungsdetails der Richtliniengruppen als Teil der Zulassungsantwort .status.details.causes, wenn eine Richtliniengruppe eine Ablehnung vornimmt.

Sie können die vollständigen Details einer abgelehnten Zulassungsanfrage erhalten, indem Sie das Verbosity-Level von kubectl erhöhen:

kubectl -v4 apply -f signed-pod.yml
I0919 18:29:40.251332    4330 helpers.go:246] server response object: [{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "error when creating \"signed-pod.yml\": admission webhook \"clusterwide-demo.kubewarden.admission\" denied the request: the image is using the latest tag or is not signed by Alice and Bob",
  "details": {
    "causes": [
      {
        "message": "Resource signed is not accepted: verification of image testing.registry.svc.lan/busybox:latest failed: Host error: Callback evaluation failure: Image verification failed: missing signatures\nThe following constraints were not satisfied:\nkind: pubKey\nowner: null\nkey: |\n  -----BEGIN PUBLIC KEY-----\n  MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEswA3Ec4w1ErOpeLPfCdkrh8jvk3X\n  urm8ZrXi4S3an70k8bf1OlGnI/aHCcGleewHbBk1iByySMwr8BabchXGSg==\n  -----END PUBLIC KEY-----\nannotations: null\n",
        "field": "spec.policies.signed_by_bob"
      },
      {
        "message": "not allowed, reported errors: tags not allowed: latest",
        "field": "spec.policies.reject_latest"
      }
    ]
  },
  "code": 400
}]
Error from server: error when creating "signed-pod.yml": admission webhook "clusterwide-demo.kubewarden.admission" denied the request: the image is using the latest tag or is not signed by Alice and Bob

Die vollständige Zulassungsantwort ist in den Protokollen des Richtlinienservers verfügbar, wenn dieser im Debug-Modus läuft. Darüber hinaus sind die Bewertungsdetails immer Teil der von des Richtlinienservers ausgegebenen OpenTelemetry-Traces.

Kontextabhängige Richtlinien

Ein weiterer Unterschied zwischen Richtliniengruppen und gewöhnlichen Richtlinien ist der Standort der Definition kontextabhängiger Ressourcenregeln. Jede Richtlinie in einer Richtliniengruppe akzeptiert ein optionales contextAwareResources-Feld, um die Ressourcen anzugeben, auf die die Richtlinie während der Bewertung zugreifen kann. Ähnlich wie bei gewöhnlichen Richtlinien können Sie kontextabhängige Funktionen nur nutzen, indem Sie eine ClusterAdmissionPolicyGroup definieren. Dies geschieht aus Sicherheitsgründen, da nur unprivilegierte Benutzer AdmissionPolicyGroup-Ressourcen bereitstellen können. Für weitere Details siehe die Dokumentation zu den kontextabhängigen Richtlinien.

Ein Beispiel für eine Richtliniengruppe, die eine kontextabhängige Richtlinie verwendet. 
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicyGroup # or AdmissionPolicyGroup
metadata:
  name: demo-ctx-aware
spec:
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - services
      operations:
        - CREATE
        - UPDATE
  policies:
    unique_service_selector:
      module: registry://ghcr.io/kubewarden/policies/unique-service-selector-policy:v0.1.0
      contextAwareResources:
        - apiVersion: v1
          kind: Service
      settings:
        app.kubernetes.io/name: MyApp
    owned_by_foo_team:
      module: registry://ghcr.io/kubewarden/policies/safe-annotations:v0.2.9
      settings:
        mandatory_annotations:
          - owner
        constrained_annotations:
          owner: "foo-team"
  expression: "unique_service_selector() || (!unique_service_selector() && owned_by_foo_team())"
  message: "the service selector is not unique or the service is not owned by the foo team"

Im vorherigen Beispiel kann die unique_service_selector-Richtlinie auf die Service-Ressource zugreifen. Die owned_by_foo_team hat jedoch keinen Zugriff auf Kubernetes-Ressourcen.

Validierung der Einstellungen

Wenn der Richtlinienserver startet, validiert er die Einstellungen sowohl der Richtliniengruppen als auch der gewöhnlichen Richtlinien. Die Richtliniengruppen durchlaufen jedoch einen zusätzlichen Validierungsschritt, um zu überprüfen, ob der Ausdruck gültig ist und zu einem booleschen Wert evaluiert.

Audit-Scanner

Ähnlich wie bei den AdmissionPolicy- und ClusterAdmissionPolicy-CRDs gibt das backgroundAudit-Feld an, ob die Richtliniengruppe während der Audit-Prüfungen einbezogen werden soll.

Richtlinienserver

Sie können die policies.yml-Einstellungsdatei erweitern, um Richtliniengruppen neben gewöhnlichen Richtlinien einzuschließen. Wie bei gewöhnlichen Richtlinien erfolgt der Download von Modulen einmalig. Sie verwenden dasselbe Richtlinienmodul sowohl in einer Richtliniengruppe als auch in einer gewöhnlichen Richtlinie.