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.

Kontextabhängige Richtlinien

Entwickler können Richtlinien erstellen, die zur Laufzeit Informationen aus einem Kubernetes-Cluster abrufen. Dies sind kontextabhängige Richtlinien. Kontextabhängige Richtlinien können bestimmen, ob ein AdmissionRequest akzeptabel ist, indem sie Informationen von Ressourcen verwenden, die im Cluster bereitgestellt sind.

Kontextabhängige Richtlinien sind nur in SUSE Security Admission Controller Versionen ≥ v1.6.0 verfügbar.

Die Kontrolle darüber, auf welche Ressourcen eine Richtlinie im Cluster zugreifen kann, erfolgt über das Service-Konto des Richtliniendienstes. Ein Clusteradministrator kontrolliert, auf was eine Richtlinie über Kubernetes RBAC-Regeln zugreifen kann. Kontextabhängige Richtlinien haben nur Lesezugriff auf die angeforderten Ressourcen.

Aus Sicherheitsgründen können nur ClusterAdmissionPolicy Richtlinien Informationen aus dem Kubernetes-Cluster abrufen. Das liegt daran, dass unprivilegierte Benutzer AdmissionPolicy Ressourcen bereitstellen können.

Wenn ein unprivilegierter Benutzer eine kontextabhängige Richtlinie als AdmissionPolicy bereitstellt, blockiert das System:

  • Blockiert alle Versuche, auf Kubernetes-Ressourcen zuzugreifen.

  • Meldet sie an den Clusteradministrator.

Standardmäßig blockiert Admission Controller alle Clusterressourcen. Ein SUSE Security Admission Controller Administrator definiert, auf welche Kubernetes-Ressourcen jede kontextabhängige Richtlinie zugreifen kann. Dafür wird contextAwareResources verwendet.

Das folgende Beispiel stellt eine Richtlinie bereit, die den Zugriff auf die Deployment und Pod Ressourcen erfordert:

apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  name: context-aware-policy
  namespace: default
spec:
  policyServer: default
  module: "registry://ghcr.io/kubewarden/policies/context-aware-policy:v1.0.0"
  settings: {}
  contextAwareResources:
    - apiVersion: "apps/v1"
      kind: "deployment"
    - apiVersion: "v1"
      kind: "pod"
  rules:
    - apiGroups: ["apps"]
      apiVersions: ["v1"]
      resources: ["deployment"]
      operations:
        - CREATE
        - UPDATE
  mutating: false

Sobald die Richtlinie bereitgestellt ist, kann sie die Daten der deployment und pod Ressourcen lesen.

Richtlinienautoren stellen Listen von Kubernetes-Ressourcen für ihre kontextabhängige Richtlinie bereit. Richtlinienautoren tun dies, indem sie die Richtlinie annotieren. SUSE Security Admission Controller Administratoren sehen die Metadaten der Richtlinie mit dem kwctl inspect Befehl ein. Sie können eine Liste der Ressourcen abrufen, auf die die Richtlinie zugreifen muss. Ein Administrator verwendet diese Liste, um die ClusterAdmissionPolicy Definition auszufüllen.

Um Missbrauch des Systems zu verhindern, müssen SUSE Security Admission Controller Administratoren die Ressourcen überprüfen, auf die die Richtlinie zugreift.

Zum Beispiel hätte eine Richtlinie, die Ingress-Objekte bewertet, gute Gründe, die Ingress Ressourcen zu lesen, die im Cluster definiert sind. Die gleiche Richtlinie kann nicht rechtfertigen, Zugriff auf Secret Ressourcen zu haben.

Richtlinien sollten den minimalen Zugriff haben, der erforderlich ist, um korrekt zu funktionieren.

Die Identifizierung von Kubernetes-Ressourcen verwendet apiVersion und kind.

In der Regel ist apiVersion eine Zeichenkette im Format <api>/<version>. Ressourcen aus der core API-Gruppe (Pod, Service und andere) sollten den Gruppennamen <api> nicht definieren. Sie sollten nur das <version> definieren (zum Beispiel v1).

Für eine Kernel-Ressource funktioniert die erste nicht, die zweite schon.

- apiVersion: "core/v1"
  kind: "pod"
- apiVersion: "v1"
  kind: "pod"

Alle anderen Kubernetes-Ressourcen benötigen die vollständige Definition: <api>/<version>.

Weiterführende Literatur

Sie finden detailliertere Informationen zu kontextabhängige Richtlinien in diesem Abschnitt der Referenzdokumentation.