Sicherheitsrichtlinie für Vertrauliche Container in Azure Kubernetes Service
Das Confidential Computing Consortium (CCC) beschreibt Folgendes: „Confidential Computing ist der Schutz verwendeter Daten, indem Berechnungen in einer hardwarebasierten, zertifizierten Trusted Execution Environment (TEE) durchgeführt werden.“ Vertrauliche AKS-Container wurden entwickelt, um verwendete Daten in Kubernetes-Pods vor unbefugtem Zugriff von außerhalb dieser Pods geschützt werden. Jeder Pod wird auf einer Hilfs-VM (Utility VM, UVM) ausgeführt, die durch AMD SEV-SNP TEE geschützt ist, indem verwendete Daten verschlüsselt werden und der Zugriff auf die Daten vom Hostbetriebssystem verhindert wird. Microsoft-Techniker haben mit den Open-Source-Communitys Vertrauliche Container (Confidential Containers, CoCo) und Kata Containers beim Design und der Implementierung der vertraulichen Container zusammengearbeitet.
Übersicht über Sicherheitsrichtlinien
Einer der Hauptkomponenten der Kata Containers-Systemarchitektur ist der Kata-Agent. Bei Verwendung von Kata-Containern zur Implementierung vertraulicher Container wird der Agent innerhalb der hardwarebasierten TEE ausgeführt und ist daher Teil der vertrauenswürdigen Computingbasis (Trusted Computing Base, TCB) des Pods. Wie im folgenden Diagramm dargestellt, stellt der Kata-Agent eine Reihe von ttrpc-APIs bereit, die es den Systemkomponenten außerhalb der TEE ermöglichen, auf Vertraulichkeit basierende Kubernetes-Pods zu erstellen und zu verwalten. Diese anderen Komponenten (z. B. Kata-Shim) sind nicht Teil der TCB des Pods. Daher muss sich der Agent vor potenziell fehlerhaften oder bösartigen API-Aufrufen schützen.
In vertraulichen AKS-Containern wird der Selbstschutz der Kata-Agent-API mithilfe einer Sicherheitsrichtlinie implementiert (auch bekannt als Kata-Agent-Richtlinie), die von den Besitzern der vertraulichen Pods festgelegt wird. Das Richtliniendokument enthält Regeln und Daten, die den einzelnen Pods entsprechen, und verwendet dabei den Branchenstandard Rego-Richtliniensprache. Die Durchsetzung der Richtlinie innerhalb der Hilfs-VM (UVM) wird mit dem Open Policy Agent (OPA) implementiert – einem fortgeschrittenen Projekt der Cloud Native Computing Foundation (CNCF).
Richtlinieninhalte
Die Sicherheitsrichtlinie beschreibt alle Aufrufe der ttrpc-APIs des Agents (und die Parameter dieser API-Aufrufe), die für das Erstellen und Verwalten des vertraulichen Pods erwartet werden. Das Richtliniendokument für jeden Pod ist eine Textdatei, welche die Sprache „Rego“ verwendet. Es gibt drei allgemeine Abschnitte im Richtliniendokument.
Daten
Die Richtliniendaten sind für jeden Pod spezifisch. Sie enthalten z. B. Folgendes:
- Eine Liste der Container, die im Pod erstellt werden sollen.
- Eine Liste der APIs, die standardmäßig von der Richtlinie blockiert werden (aus Gründen der Vertraulichkeit).
Beispiele für Daten, die im Richtliniendokument für jeden Container in einem Pod enthalten sind:
- Informationen zur Imageintegrität.
- Befehle, die im Container ausgeführt werden.
- Speichervolumes und Einbindungen.
- Ausführungssicherheitskontext. Ist das Stammdateisystem beispielsweise schreibgeschützt?
- Darf der Prozess neue Berechtigungen erhalten?
- Umgebungsvariablen.
- Andere Felder aus der OCI (Open Container Initiative)-Containerlaufzeitkonfiguration.
Regeln
Die Richtlinienregeln, die im Rego-Format angegeben sind, werden von OPA für jeden Kata-Agent-API-Aufruf von außerhalb der Hilfs-VM (UVM) ausgeführt. Der Agent stellt alle API-Eingaben für OPA bereit, und OPA verwendet die Regeln, um zu überprüfen, ob die Eingaben mit Richtliniendaten übereinstimmen. Wenn die Richtlinienregeln und -daten keine API-Eingaben zulassen, lehnt der Agent den API-Aufruf ab, indem er eine Fehlermeldung „durch Richtlinie blockiert“ zurückgibt. Hier sind einige Regelbeispiele:
- Jede Containerebene wird als schreibgeschütztes virtio block-Gerät für die Hilfs-VM (UVM) verfügbar gemacht. Die Integrität dieser blockierenden Geräte wird mithilfe der dm-verity-Technologie des Linux-Kernels geschützt. Der erwartete Stammwert der dm-verity-Hashstruktur ist in den Richtliniendaten enthalten und wird zur Laufzeit durch die Richtlinienregeln überprüft.
- Regeln lehnen die Erstellung von Containern ab, wenn eine unerwartete Befehlszeile, eine Speichereinbindung, ein Ausführungssicherheitskontext oder eine Umgebungsvariable erkannt wird.
Standardmäßig gelten Regeln einer Richtlinie für alle Pods. Das genpolicy-Tool generiert die Richtliniendaten und ist für jeden Pod spezifisch.
Standardwerte
Beim Auswerten der Rego-Regeln mithilfe der Richtliniendaten und API-Eingaben als Parameter versucht OPA, mindestens einen Satz von Regeln zu finden, der einen true-Wert basierend auf den Eingabedaten zurückgibt. Wenn die Regeln true nicht zurückgegeben, gibt OPA den Standardwert für diese API an den Agent zurück. Beispiele für Standardwerte aus der Richtlinie:
default CreateContainerRequest := false– bedeutet, dass jeder CreateContainer-API-Aufruf abgelehnt wird, es sei denn, ein Satz von Richtlinienregeln lässt diesen Aufruf explizit zu.default GuestDetailsRequest := true– bedeutet, dass Aufrufe von außerhalb der TEE an die GuestDetails-API immer zulässig sind, da die von dieser API zurückgegebenen Daten für die Vertraulichkeit der Kundenworkloads nicht sensibel sind.
Senden der Richtlinie an den Kata-Agent
Alle Hilfs-VMs (UVM) vertraulicher AKS-Container starten mit einer generischen Standardrichtlinie, die im Stammdateisystem der UVM enthalten ist. Daher muss dem Agent zur Laufzeit eine Richtlinie bereitgestellt werden, die der tatsächlichen Kundenworkload entspricht. Der Richtlinientext ist wie zuvor beschrieben in Ihre YAML-Manifestdatei eingebettet und wird dem Agent auf diese Weise bereits während der UVM-Initialisierung bereitgestellt. Die Richtlinienanmerkung durchläuft die Komponenten kubelet, containerd und Kata-Shim des Systems „Vertrauliche AKS-Container“. Anschließend erzwingt der Agent, der mit OPA zusammenarbeitet, die Richtlinie für alle Aufrufe seiner eigenen APIs.
Die Richtlinie wird mithilfe von Komponenten bereitgestellt, die nicht Teil Ihrer TCB sind, daher ist diese Richtlinie zunächst nicht vertrauenswürdig. Die Vertrauenswürdigkeit der Richtlinie muss über den Remotenachweis hergestellt werden, wie im folgenden Abschnitt beschrieben.
Einrichten der Vertrauensstellung im Richtliniendokument
Vor dem Erstellen der Hilfs-VM (UVM) berechnet der Kata-Shim den SHA256-Hash des Richtliniendokuments und fügt diesen Hashwert an die TEE an. Diese Aktion erstellt eine starke Bindung zwischen dem Inhalt der Richtlinie und der Hilfs-VM (UVM). Dieses TEE-Feld kann später weder von der im UVM ausgeführten Software noch von außerhalb geändert werden.
Beim Empfang der Richtlinie überprüft der Agent den Hash der Richtlinie mit dem unveränderlichen TEE-Feld. Der Agent lehnt die eingehende Richtlinie ab, wenn eine Hash-Unstimmigkeit erkannt wird.
Vor der Verarbeitung vertraulicher Informationen müssen Ihre Workloads Remotenachweisschritte ausführen, um allen vertrauenden Seiten zu beweisen, dass die Workload mit den erwarteten Versionen der TEE, des Betriebssystems, des Agenten, des OPA und des Stammdateisystems ausgeführt wird. Der Nachweis wird in einem Container implementiert, der innerhalb der Hilfs-VM (UVM) ausgeführt wird, die signierte Nachweisbeweise von der AMD SEV-SNP-Hardware erhält. Eines der Felder aus dem Nachweisbeweis ist das weiter oben beschriebene TEE-Feld für den Hash der Richtlinie. Daher kann der Nachweisdienst die Integrität der Richtlinie überprüfen, indem der Wert dieses Felds mit dem erwarteten Hash der Pod-Richtlinie verglichen wird.
Richtlinienerzwingung
Der Kata-Agent ist für die Durchsetzung der Richtlinie verantwortlich. Microsoft hat der Kata- und CoCo-Gemeinschaft den Agentencode zur Verfügung gestellt, der für die Überprüfung der Richtlinie für jeden ttrpc-API-Aufruf eines Agenten zuständig ist. Bevor der Agent die der API entsprechenden Aktionen ausführt, verwendet er die OPA-REST-API, um zu überprüfen, ob die Richtlinienregeln und Daten den Aufruf erlauben oder blockieren.