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.

Konfigurieren von Richtlinien

Überspringen von Namespaces für eine spezifische Richtlinie

Standardmäßig gelten Richtlinien für alle Namespaces, für die der PolicyServer konfiguriert ist. Wenn Sie möchten, dass eine Richtlinie nur spezifische Namespaces anvisiert, können Sie mehrere AdmissionPolicies in jedem Namespace bereitstellen.

Eine weitere Möglichkeit besteht darin, ClusterAdmissionPolicies zu konfigurieren, indem deren spec.namespaceSelector festgelegt wird (siehe CRD-Dokumentation). Die spec.namespaceSelector entscheidet, ob die Richtlinie auf ein Objekt angewendet wird, basierend darauf, ob der Namespace für dieses Objekt mit dem Selektor übereinstimmt.

Hier ist eine Richtlinie, die nur die kube-system und my-namespace Namespaces anvisiert:

---
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psa-enforcer-privileged-namespaces
spec:
  module: registry://ghcr.io/kubewarden/policies/psa-label-enforcer:v1.0.3
  rules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["namespaces"]
      operations:
        - CREATE
        - UPDATE
  mutating: true
  namespaceSelector:
    matchExpressions:
      - key: "kubernetes.io/metadata.name"
        operator: In
        values: [kube-system, my-namespace]
  settings:
    modes:
      enforce: "privileged"

Hier ist eine Richtlinie, die alle Namespaces außer den kube-system und my-namespace anvisiert:

---
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: psa-enforcer-default-mode
spec:
  module: registry://ghcr.io/kubewarden/policies/psa-label-enforcer:v1.0.3
  rules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["namespaces"]
      operations:
        - CREATE
        - UPDATE
  mutating: true
  namespaceSelector:
    matchExpressions:
      - key: "kubernetes.io/metadata.name"
        operator: NotIn
        values: [kube-system, my-namespace]
  settings:
    modes:
      enforce: "restricted"

Benutzerdefinierte Ablehnungsnachricht

Wenn eine Richtlinie eine Ressource ablehnt, ist die dem Benutzer angezeigte Nachricht die, die vom Autor der Richtlinie verfasst wurde. Manchmal möchten Clusterbetreiber möglicherweise eine benutzerdefinierte Ablehnungsnachricht festlegen. Zum Beispiel kann dies verwendet werden, um auf ein internes Wiki zu verweisen oder um einen spezifischeren Fehlercode bereitzustellen.

Das message Feld in den ClusterAdmissionPolicy und AdmissionPolicy Typen kann verwendet werden, um dies zu erreichen.

ClusterAdmissionPolicyGroup und AdmissionPolicyGroup haben bereits ein message Feld, das sich auf die gleiche Weise verhält.

Das message Feld ermöglicht es Clusterbetreibern, eine benutzerdefinierte Ablehnungsnachricht zu definieren, die die von der Richtlinie zurückgegebene überschreibt. Bei Verwendung dieser Konfiguration kann die ursprüngliche Ablehnungsnachricht im causes-Feld der Antwort gefunden werden.

apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: pod-privileged-with-message
spec:
  module: registry://ghcr.io/kubewarden/policies/pod-privileged:1.0.2
  policyServer: default
  mode: protect
  message: "Nops! You cannot do that"
  settings: {}
  rules:
    - apiGroups:
        - ""
      apiVersions:
        - v1
      resources:
        - "*"
      operations:
        - CREATE
  mutating: false

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

$ kubectl -v4 run pod-privileged2 --image=registry.k8s.io/pause --privileged
I0612 16:32:43.647601   48424 cert_rotation.go:137] Starting client certificate rotation controller
I0612 16:32:43.662550   48424 helpers.go:246] server response object: [{
  "metadata": {},
  "status": "Failure",
  "message": "admission webhook \"clusterwide-pod-privileged-with-message.kubewarden.admission\" denied the request: Nops! You cannot do that",
  "details": {
    "causes": [
      {
        "message": "Privileged container is not allowed"
      }
    ]
  },
  "code": 400
}]

Ein Ergebnis einer Richtlinie zu negieren, indem man es in eine PolicyGroup kapselt.

Manchmal implementiert eine Richtlinie nicht die umgekehrte Logik dessen, was Sie benötigen.

Zum Beispiel möchten Sie die priority-class Richtlinie verwenden, um eine Reihe von Prioritätsklassen abzulehnen. Aber zum Zeitpunkt des Schreibens unterstützt die priority-class-Richtlinie nur Erlauben-Listen, nicht Ablehnen-Listen.

Ein häufiges Muster ist es, Ihre Richtlinie in eine AdmissionPolicyGroup oder ClusterAdmissionPolicyGroup einzuwickeln und das Ergebnis der Richtlinie in ihrer spec.expression zu negieren.

Zum Beispiel nehmen wir an, wir möchten, dass die Benutzer alle Prioritätsklassen verwenden, die innerhalb des Clusters definiert sind, mit Ausnahme einer der folgenden: low-priority, med-priority und high-priority.

Derzeit erlauben die Richtlinieneinstellungen nur, die Liste der erlaubten Prioritätsklassen auszudrücken. Die folgende Gruppenrichtlinie überwindet diese Einschränkung.

apiVersion: policies.kubewarden.io/v1
kind: AdmissionPolicyGroup
metadata:
  name: priority-class-denylist
  namespace: your-namespace # or use a CLusterAdmissionPolicyGroup and set spec.namespaceSelector
spec:
  rules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["pods"]
      operations: ["CREATE", "UPDATE"]
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["replicationcontrollers"]
      operations: ["CREATE", "UPDATE"]
    - apiGroups: ["apps"]
      apiVersions: ["v1"]
      resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]
      operations: ["CREATE", "UPDATE"]
    - apiGroups: ["batch"]
      apiVersions: ["v1"]
      resources: ["jobs", "cronjobs"]
      operations: ["CREATE", "UPDATE"]
  policies:
    is_a_denied_priority_class:
      module: ghcr.io/kubewarden/policies/priority-class-policy:v1.0.4
      settings:
        allowed_priority_classes:
          - low-priority
          - med-priority
          - high-priority
  expression: "!is_a_denied_priority_class()" # negated result
  message: "the Pod is using a priorityClass that is not allowed"