Zusammenfassung

  • Eine ValidatingAdmissionPolicyBinding verbindet Richtlinie, möglichen Geltungsbereich, optionale Parameter und deklarierte Aktionen; sie ist kein Beleg für das Ergebnis einer einzelnen API-Anfrage.
  • Kubernetes trennt Ressourcenabgleich, Parameterauflösung, Ausdrucksauswertung, Fehlerbehandlung, Aktionswahl und Antwort.
  • Belastbare Governance bewahrt die beobachtete Konfiguration und den anfragebezogenen Ausgang als unterschiedliche, zurechenbare Aufzeichnungen auf.

Eine Richtlinienbindung sieht auf den ersten Blick wie ein fertiger Vollzugsbeschluss aus. Ein Richtlinienname ist sichtbar, Ressourcen werden eingegrenzt und Aktionen wie Deny, Warn oder Audit sind notiert. Daraus wird schnell der Satz: „Diese Regel wird durchgesetzt.“ Tatsächlich beschreibt die Bindung zunächst eine beabsichtigte Verbindung zwischen Richtlinienlogik, Bereich und möglichen Parametern. Sie nennt keine Anfrage, keine anfragende Identität, keinen Auswertungszeitpunkt und keine Antwort des API-Servers.

Die Kubernetes-Referenz beschreibt die erste Grenze ausdrücklich. Eine ValidatingAdmissionPolicyBinding bindet eine ValidatingAdmissionPolicy an parametrisierte Ressourcen. Die matchResources der Bindung werden mit den matchConstraints der Richtlinie geschnitten. Eine Anfrage muss daher zuerst die Richtlinienbedingungen erfüllen, bevor die Bindung sie weiter auswählen kann. Das erklärt einen möglichen Prüfpfad. Es beweist nicht, dass ein bestimmtes Objekt diesen Schnitt tatsächlich durchlaufen hat. Eine passende Anfrage kann ausgeblieben sein, außerhalb der Bedingungen gelegen haben oder später von einem anderen Controller verändert oder abgelehnt worden sein.

Auch die Parameterreferenz ist keine Ergebnisbehauptung. Eine Bindung kann auf eine Ressource zeigen, die eine Richtlinie parametrisiert. Kubernetes unterscheidet jedoch zwischen einer vorhandenen und einer fehlenden Referenz; Letztere kann die Bindung fehlkonfigurieren und die Fehlerpolitik der Richtlinie relevant machen. Richtlinie, Bindung, Parameterressource und Fehlerpolitik sind getrennte Konfigurationsflächen. Ihre Erfassung ist nützlich. Sie beweist weder, dass eine Arbeitslast zugelassen wurde, noch dass eine konkrete Anfrage abgewiesen wurde.

Besonders wichtig ist die Unterscheidung zwischen failurePolicy und einem Validierungsausdruck, der false ergibt. Kubernetes verwendet die Fehlerpolitik für Analyse-, Typprüfungs-, Laufzeit- und Konfigurationsfehler. Wie eine false-Validierung behandelt wird, wird durch die validationActions der Bindung erklärt. Deny führt bei einem Validierungsfehler zur abgelehnten Anfrage, Warn meldet eine Warnung an den Client und Audit nimmt den Fehler in das Audit-Ereignis der Anfrage auf. Das sind keine austauschbaren Etiketten für „geschützt“. Sie gehören zu unterschiedlichen Sachverhalten: Fehler, Ausdrucksergebnis, deklarierte Aktion und sichtbare Reaktion.

Die Stellung der Zulassung im Ablauf begrenzt die Aussage weiter. Kubernetes ordnet Admission Controller nach Authentifizierung und Autorisierung, aber vor der Persistenz ein. Mutierende und validierende Phasen sind getrennt; eine Ablehnung in einer von ihnen beendet die Anfrage. Aus der Bindung ist nicht ersichtlich, ob die vorherige Autorisierung die Operation erlaubte, ob eine Mutation das Objekt veränderte, ob ein anderer Controller entschied oder ob das Objekt gespeichert wurde. Lesezugriffe umgehen die Zulassungsschicht. Eine Bindungsliste ist also keine vollständige Geschichte dessen, was ein Cluster angenommen oder behalten hat.

Anfragebezogene Auditbelege zeigen den Unterschied. Kubernetes dokumentiert für einen Validierungsfehler eine Audit-Anmerkung, die Richtlinie, Bindung, Ausdruck und Aktionen für die betreffende API-Anfrage benennt. Sie stützt eine eng begrenzte Aussage über diese Anfrage. Sie stützt nicht ohne weitere Belege dieselbe Aussage über andere Ressourcen, frühere Zeiträume oder die Sicherheit des gesamten Clusters. Gerade die enge Zuordnung macht sie überprüfbar.

Eine brauchbare Praxis führt deshalb zwei Nachweise. Der Konfigurationsnachweis hält Identität und beobachtete Version von Richtlinie und Bindung, Bereich, Parameterreferenz, Fehlerpolitik, Aktionen und Beobachtungszeit fest. Der Ergebnisnachweis hält Anfrageidentität und Zeit, Übereinstimmung oder Ausschluss, Parameterzustand, Auswertung, Aktion, Antwort und Beleg für Speicherung oder Ablehnung fest. Dieses Schema ist keine Kubernetes-Vorschrift. Es verhindert, dass eine klare Deklaration die Autorität eines nicht belegten Ereignisses erhält.

Quellen

  1. Kubernetes-API-Referenz — ValidatingAdmissionPolicyBinding
  2. Kubernetes-API-Referenz — ValidatingAdmissionPolicy
  3. Kubernetes-Tutorial — Admission Policies
  4. Kubernetes-Dokumentation — Admission Controller
  5. Kubernetes-Dokumentation — Audit Annotations