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.

SUSE Security Admission Controller-Architektur

SUSE Security Admission Controller ist eine Kubernetes-Richtlinien-Engine. Es verwendet Richtlinien, die in einer Programmiersprache Ihrer Wahl geschrieben sind. Diese Sprache muss ein WebAssembly-Binärformat erzeugen, das SUSE Security Admission Controller verwenden kann.

Was ist eine Richtlinie?

Eine Richtlinie ist ein Open Container Initiative (OCI)-Artefakt. Es enthält ein WebAssembly-Modul, den Richtliniencode und die Metadaten, die von PolicyServer benötigt werden, um Validierungen und Mutationen von Zulassungsanfragen durchzuführen.

Wie Kubernetes verwendet SUSE Security Admission Controller die Begriffe 'PolicyServer', wenn über den SUSE Security Admission Controller Richtlinienserver und policy-server gesprochen wird, wenn über Pod oder Implementierung eines SUSE Security Admission Controller PolicyServers gesprochen wird.

Gestaltungsprinzipien

Nutzung von Kernel-Funktionen von Kubernetes

Das Team hat SUSE Security Admission Controller so entworfen, dass es Kernel-Funktionen von Kubernetes nutzt, ohne das Rad neu zu erfinden. Das Projekt nutzt eine Kombination aus:

  • Kubernetes-Controller

  • Benutzerdefinierte Ressourcenbeschreibungen (CRDs)

  • Webhooks (Validierung und Mutation)

  • das Benachrichtigungssystem des Control Plane

Die Kubernetes-Architektur wird effektiv genutzt.

SUSE Security Admission Controller funktioniert nahtlos innerhalb des Kubernetes-Ökosystems. Im Kernel ist der SUSE Security Admission Controller Controller ein Kubernetes-Controller, der SUSE Security Admission Controller benutzerdefinierte Ressourcenbeschreibungen (CRDs) überwacht und Kubernetes-Ressourcen konfiguriert, um sie auszuführen. Diese Integration stellt sicher, dass SUSE Security Admission Controller die integrierten Kubernetes-Mechanismen wie Controller und CRDs nutzt, um Sicherheitsrichtlinien effizient zu überwachen, zu verwalten und anzuwenden.

Erweiterbare Richtliniendefinition

SUSE Security Admission Controller verwendet benutzerdefinierte Ressourcenbeschreibungen (CRDs), um SUSE Security Admission Controller Ressourcen zu definieren und zu verwalten, die die Regeln für die Validierung von Zulassungsanfragen festlegen. Dieses Design ermöglicht es Benutzern, die Fähigkeiten von Kubernetes mit benutzerdefinierten Zulassungssteuerungen zu erweitern und sicherzustellen, dass die Durchsetzung von Sicherheits- und Compliance-Richtlinien im gesamten Cluster konsistent ist.

Direkte Zulassungssteuerung

Wenn der SUSE Security Admission Controller Controller eingerichtet wird, erhält der Policy-Server-Dienst Zulassungsanfragen direkt vom Kubernetes-Control-Plane unter Verwendung von ValidationWebhooks und MutatingWebhooks. Diese direkte Interaktion optimiert den Zulassungssteuerungsprozess, reduziert die Latenz und erhöht die Effizienz bei der Durchsetzung von Richtlinien.

WebAssembly bietet eine sandboxed Ausführungsumgebung, die sicherstellt, dass Richtlinien isoliert ausgeführt werden, wodurch die Sicherheit und Stabilität des Mechanismus zur Durchsetzung von Richtlinien verbessert wird. Diese Isolation verhindert, dass Richtlinien sich gegenseitig oder mit dem Host-System interferieren, wodurch das Risiko der Ausführung von bösartigem Code gemindert wird. WebAssembly ist portabel und effizient, sodass Richtlinien in verschiedenen Umgebungen ohne Modifikation ausgeführt werden können. Diese plattformübergreifende Kompatibilität stellt sicher, dass SUSE Security Admission Controller Richtlinien vielseitig sind, sodass Sie sie auf verschiedenen Kubernetes-Clustern verteilen und ausführen können.

OCI-basierte Richtlinienartefakte

Richtlinien in SUSE Security Admission Controller sind OCI (Open Container Initiative) Artefakte. Diese Standardisierung erleichtert die Verteilung und Versionierung von Richtlinien. Richtlinien enthalten sowohl die WebAssembly-Module für die Durchsetzungslogik als auch die für den Betrieb des PolicyServers erforderlichen Metadaten. Die Verwendung von OCI-Artefakten fördert die Interoperabilität und die einfache Verwaltung innerhalb von Cloud-Ökosystemen.

Fein abgestufte Richtlinienanwendung

SUSE Security Admission Controller verknüpft Richtlinien mit ihrem eigenen 'Validierungs-' oder 'Mutations-'Webhook, was eine fein abgestufte Anwendung von Zulassungssteuerungen ermöglicht. Diese Flexibilität ermöglicht es Administratoren, die Durchsetzung von Richtlinien an spezifische Bedürfnisse anzupassen und die Sicherheits- und Compliance-Position des Kubernetes-Clusters zu verbessern.

Der SUSE Security Admission Controller Stack

SUSE Security Admission Controller besteht aus diesen Komponenten:

  • SUSE Security Admission Controller Benutzerdefinierte Ressourcen sind Kubernetes Benutzerdefinierte Ressourcen, die den Prozess der Verwaltung von Richtlinien vereinfachen.

    SUSE Security Admission Controller integriert sich mit Kubernetes unter Verwendung von Dynamische Zulassungssteuerung. Insbesondere fungiert SUSE Security Admission Controller als ein Kubernetes Zulassungs-Webhook. Der policy-server ist der Webhook-Endpunkt, der vom Kubernetes API-Server aufgerufen wird, um Anfragen zu validieren.

  • Der SUSE Security Admission Controller Controller ist ein Kubernetes-Controller, der die SUSE Security Admission Controller Benutzerdefinierten Ressourcen abgleicht. Dieser Controller erstellt Teile des SUSE Security Admission Controller Stacks. Er übersetzt auch die SUSE Security Admission Controller Konfiguration in Kubernetes-Direktiven.

    Der kubewarden-controller registriert die benötigten MutatingWebhookConfiguration oder ValidatingWebhookConfiguration Objekte beim Kubernetes API-Server.

  • SUSE Security Admission Controller Richtlinien sind WebAssembly-Module, die die Validierungs- oder Mutationslogik enthalten. WebAssembly-Module haben detaillierte Dokumentation in den Richtlinien schreiben Abschnitten.

  • Der PolicyServer erhält Anfragen zur Validierung. Er validiert die Anfragen, indem er SUSE Security Admission Controller Richtlinien ausführt.

  • Der Audit-Scanner inspiziert die bereits im Cluster vorhandenen Ressourcen. Er identifiziert diejenigen, die gegen SUSE Security Admission Controller Richtlinien verstoßen.

    Audit-Scanner überprüft ständig die im Cluster deklarierten Ressourcen und kennzeichnet die, die nicht mehr den bereitgestellten SUSE Security Admission Controller Richtlinien entsprechen.

    %%{ init: { "flowchart": { "htmlLabels": false, } } }%% graph LR accTitle: Admission Controller architecture accDescr: A diagram showing the architecture of Admission Controller components. subgraph " " direction LR subgraph " " direction LR k8s(("Kubernetes")) registry[("OCI registry")] end subgraph kw["`**Admission Controller**`"] controller("`**Controller**`") subgraph policy-server["`**policy-server**`"] direction LR kw-policy-1{{"Policy 1"}} kw-policy-2{{"Policy 2"}} kw-policy-3{{"Policy 3"}} end webhooks(["ValidationWebhooks and\nMutatingWebhooks"]) audit-scanner["KW audit scanner"] end end policy-server -->|"downloads\npolicies from"| registry controller -->|"watches for\nevents"| k8s controller -->|"creates"| webhooks controller -->|"creates\npolicy-server\ninstances"| policy-server k8s -. "sends admission\nrequests using" .-> webhooks webhooks -. "sent admission\nrequests from K8s" .-> policy-server audit-scanner -->|"sends audit\nadmission requests"| policy-server
    Figure 1. Architektur

Die Reise einer SUSE Security Admission Controller Richtlinie

Standard PolicyServer

In einem neuen Cluster sind die definierten SUSE Security Admission Controller Komponenten:

  • Benutzerdefinierte Ressourcenbeschreibungen (CRD)

  • Die kubewarden-controller Implementierung

  • Eine benutzerdefinierte Ressource namens default für den PolicyServer.

Wenn der kubewarden-controller die Standard-PolicyServer-Ressource bemerkt, erstellt er eine policy-server Implementierung der PolicyServer-Komponente.

SUSE Security Admission Controller fungiert als Kubernetes Admission Webhook. Kubernetes gibt an, dass Transport Layer Security (TLS) verwendet werden soll, um alle Webhook-Endpunkte zu sichern. Das kubewarden-controller richtet diese sichere Kommunikation ein durch:

  1. Erzeugen einer selbstsignierten Zertifizierungsstelle

  2. Verwenden Sie diese CA, um einen TLS-Zertifikatsschlüssel für den policy-server Dienst zu generieren.

Diese Objekte werden alle als Secret Ressourcen in Kubernetes gespeichert.

Schließlich erstellt kubewarden-controller die policy-server Implementierung und einen Kubernetes ClusterIP-Dienst, um sie im Cluster-Netzwerk bereitzustellen.

Die erste Richtlinie definieren

Eine Richtlinie muss definieren, auf welchem policy-server sie ausgeführt werden soll. Es bindet an eine policy-server Instanz. Sie können verschiedene Richtlinien mit demselben Wasm-Modul und denselben Einstellungen in vielen PolicyServern ausführen. Allerdings kann es keine einzelne Richtliniedefinition geben, die in vielen PolicyServern ausgeführt wird.

Der kubewarden-controller bemerkt die neue ClusterAdmissionPolicy Ressource und findet so die gebundene policy-server und gleicht sie ab.

Abgleich eines policy-server

Beim Erstellen, Ändern oder Löschen eines ClusterAdmissionPolicy oder AdmissionPolicy wird eine Abgleichschleife in kubewarden-controller aktiviert, für den policy-server, der die Richtlinie besitzt. Diese Abgleichsschleife erstellt ein ConfigMap mit allen an die policy-server gebundenen Richtlinien. Dann beginnt die Implementierungs-Rollout des policy-server. Dies führt dazu, dass die neue policy-server-Instanz mit der aktualisierten Konfiguration gestartet wird.

Zum Startzeitpunkt liest der policy-server seine Konfiguration aus der ConfigMap und lädt alle angegebenen SUSE Security Admission Controller Richtlinien herunter. Sie können SUSE Security Admission Controller Richtlinien von entfernten HTTP-Servern und Container-Registries herunterladen.

Sie verwenden die Parameter der Richtlinieneinstellungen, um das Verhalten einer Richtlinie anzupassen. Nach dem Start und dem Herunterladen der Richtlinien überprüft der policy-server, ob die vom Benutzer bereitgestellten Richtlinieneinstellungen gültig sind.

Der policy-server validiert die Richtlinieneinstellungen, indem er die validate_setting-Funktion aufruft, die von jeder Richtlinie bereitgestellt wird. Es gibt weitere Dokumentation im Abschnitt Spezifikationsreferenz der Dokumentation.

Wenn irgendwelche Richtlinien falsche Konfigurationsparameter aus der Richtlinienspezifikation des Benutzers erhalten haben, geben alle Zulassungsanfragen, die von dieser Richtlinie bewertet werden, einen Fehler zurück.

Wenn SUSE Security Admission Controller alle Richtlinien konfiguriert hat, erzeugt der policy-server einen Pool von Worker-Threads, um eingehende Anfragen mit den vom Benutzer angegebenen SUSE Security Admission Controller Richtlinien zu bewerten.

Schließlich startet der policy-server einen HTTPS-Server, der auf eingehende Validierungsanfragen überwacht. Der SUSE Security Admission Controller verwendet den TLS-Schlüssel und das Zertifikat, die vom SUSE Security Admission Controller Controller erstellt wurden, um den Webserver abzusichern.

Der Webserver macht jede Richtlinie über einen dedizierten Pfad, gemäß der Namenskonvention /validate/<policy ID>, zugänglich.

Kubernetes wird über die Richtlinie informiert.

Alle policy-server Instanzen haben ein Readiness Probe, das kubewarden-controller verwendet, um zu überprüfen, wann die policy-server Implementierung bereit ist, eine AdmissionReview zu bewerten.

Sobald SUSE Security Admission Controller die policy-server Implementierung als 'einzigartig erreichbar' oder Ready markiert, macht der kubewarden-controller den Kubernetes API-Server auf die neue Richtlinie aufmerksam. Dies geschieht durch die Erstellung entweder eines MutatingWebhookConfiguration oder eines ValidatingWebhookConfiguration Objekts. In diesem Kontext bedeutet 'einzigartig erreichbar', dass alle PolicyServer-Instanzen im Cluster die neueste Richtlinienkonfiguration installiert haben. Die Unterscheidung ist ein feiner Punkt, aber notwendig aufgrund der Funktionsweise des Rollouts von PolicyServern. Es ist möglich, die gleiche Richtlinie auf verschiedenen PolicyServern mit unterschiedlichen Konfigurationen zu haben.

Jede Richtlinie hat einen dedizierten MutatingWebhookConfiguration oder ValidatingWebhookConfiguration, der auf den von policy-server bereitgestellten Webhook-Endpunkt verweist. Der Endpunkt ist unter der /validate/<policy ID> URL erreichbar.

Richtlinie in Aktion

Jetzt, da alle notwendigen Vorbereitungen abgeschlossen sind, beginnt Kubernetes, Admission Review-Anfragen an die richtigen policy-server Endpunkte zu senden.

Ein policy-server empfängt das Admission Request-Objekt und verwendet, basierend auf dem Endpunkt, der die Anfrage erhalten hat, die richtige Richtlinie zur Bewertung.

SUSE Security Admission Controller bewertet jede Richtlinie in seiner eigenen dedizierten WebAssembly-Sandbox. Die Kommunikation zwischen einer policy-server Instanz (dem "Host") und der WebAssembly-Richtlinie (dem "Gast") verwendet das waPC-Kommunikationsprotokoll. Die Beschreibung des Protokolls ist Teil der Richtlinien schreiben Dokumentation. Richtlinien können auch die von der Web Assembly System Interface (WASI) bereitgestellten Schnittstellen nutzen.

Wie SUSE Security Admission Controller viele PolicyServer und Richtlinien verwaltet.

Ein Cluster kann viele PolicyServer und SUSE Security Admission Controller Richtlinien definiert haben. Es gibt Vorteile, viele PolicyServer zu haben:

  • Sie können störende Namespaces oder Mandanten – beziehungsweise solche, die viele Richtlinienbewertungen erzeugen – vom Rest des Clusters isolieren, um andere Clusteroperationen nicht negativ zu beeinflussen.

  • Sie können geschäftskritische Richtlinien in einem dedizierten PolicyServer-Pool ausführen, wodurch Ihre Infrastruktur widerstandsfähiger wird.

Eine PolicyServer-Ressource definiert jede policy-server und eine ClusterAdmissionPolicy oder AdmissionPolicy Ressource definiert jede Richtlinie.

Ein ClusterAdmissionPolicy und ein AdmissionPolicy binden an ein policy-server. Jede ClusterAdmissionPolicy, die kein policy-server angibt, bindet an den Standard-PolicyServer. Wenn ein ClusterAdmissionPolicy auf ein policy-server verweist, das nicht existiert, ist sein Zustand unschedulable.

Jede policy-server definiert viele Validierungsendpunkte, einen für jede in ihrer Konfigurationsdatei definierten Richtlinie. Sie können dieselbe Richtlinie viele Male mit unterschiedlichen Konfigurationsparametern laden.

Die ValidatingWebhookConfiguration und MutatingWebhookConfiguration Ressourcen machen den Kubernetes API-Server auf diese Richtlinien aufmerksam. Dann synchronisiert kubewarden-controller den API-Server und die Konfigurationsressourcen.

Der Kubernetes API-Server leitet eingehende Zulassungsanfragen an den richtigen Validierungsendpunkt weiter, der von policy-server bereitgestellt wird.