Sicherheitsrichtlinie für vertrauliche Container im Azure Kubernetes-Dienst
Wie vom Confidential Computing Consortium (CCC) beschrieben, ist "Vertrauliches Computing der Schutz von Daten, die verwendet werden, indem die Berechnung in einer hardwarebasierten, attestierten Trusted Execution Environment (TEE)" durchgeführt wird. AKS Vertrauliche Container sind so konzipiert, dass Kubernetes-Pods-Daten vor unbefugtem Zugriff von außerhalb dieser Pods geschützt werden. Jeder Pod wird in einem vertraulichen virtuellen Computer (CVM) ausgeführt, der durch den AMD SEV-SNP TEE geschützt ist, indem Daten verschlüsselt und der Zugriff auf die Daten vom Hostbetriebssystem (Os) verhindert wird. Microsoft-Techniker arbeiteten mit den Open-Source-Communitys vertraulicher Container (CoCo) und Kata Containers zusammen, um die Design- und Implementierung der vertraulichen Container zu entwickeln und umzusetzen.
Übersicht über Sicherheitsrichtlinien
Einer der Standard Komponenten der Kata Containers-Systemarchitektur ist der Kata-Agent. Bei Verwendung von Kata-Containern zur Implementierung vertraulicher Container wird der Agent innerhalb des hardwarebasierten TEE ausgeführt und ist daher Teil der 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 des TEE ermöglichen, CVM-basierte Kubernetes-Pods zu erstellen und zu verwalten. Diese anderen Komponenten (z. B. kata Shim) sind nicht Teil des TCB des Pods. Daher muss sich der Agent vor potenziell fehlerhaften oder bösartigen API-Aufrufen schützen.
In AKS Vertraulichen Containern wird der Self-Protection der Kata-Agent-API mithilfe einer Sicherheitsrichtlinie implementiert (auch bekannt als Kata-Agent-Richtlinie), die von den Besitzern der vertraulichen Pods angegeben wird. Das Richtliniendokument enthält Regeln und Daten, die den einzelnen Pods entsprechen, und verwendet dabei die Branchenstandard-Rego-Richtliniensprache. Die Durchsetzung der Richtlinie innerhalb des CVM wird mithilfe des Open Policy Agent (OPA) implementiert – ein graduiertes 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 der einzelnen Pods ist eine Textdatei mit der Sprache "Rego". Es gibt drei allgemeine Abschnitte des Richtliniendokuments.
Daten
Die Richtliniendaten sind für jeden Pod spezifisch. Sie enthält 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 Bildintegrität.
- Befehle, die im Container ausgeführt werden.
- Speichervolumes und Bereitstellungen.
- Ausführungssicherheitskontext. Ist das Stammdateisystem beispielsweise schreibgeschützt?
- Darf der Prozess neue Berechtigungen erhalten?
- Umgebungsvariablen.
- Andere Felder aus der OCI-Containerlaufzeitkonfiguration (Open Container Initiative).
Regeln
Die richtlinienregeln, die im Rego-Format angegeben sind, werden von OPA für jeden Kata-Agent-API-Aufruf außerhalb des CVM 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 konsistent sind. Wenn die Richtlinienregeln und -daten keine API-Eingaben zulassen, lehnt der Agent den API-Aufruf ab, indem eine Fehlermeldung "durch Richtlinie blockiert" zurückgegeben wird. Hier sind einige Regelbeispiele:
- Jede Containerebene wird als schreibgeschütztes Virtio-Blockgerät für das CVM verfügbar gemacht. Die Integrität dieser Blockgerä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 zur Laufzeit durch die Richtlinienregeln überprüft.
- Regeln lehnen die Erstellung von Containern ab, wenn eine unerwartete Befehlszeile, speicher mount, ausführungssicherheitskontext oder Umgebungsvariable erkannt wird.
Standardmäßig gelten Richtlinienregeln 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 nicht zurückgegeben truewerden, 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 des TEEs an die GuestDetails-API immer zulässig sind, da die von dieser API zurückgegebenen Daten nicht vertraulich für die Vertraulichkeit der Kundenworkloads sind.
Senden der Richtlinie an Kata-Agent
Alle CVMs vertraulicher Container von AKS beginnen mit einer generischen Standardrichtlinie, die im Stammdateisystem für CVMs enthalten ist. Daher muss dem Agent zur Laufzeit eine Richtlinie bereitgestellt werden, die der tatsächlichen Kundenarbeitsauslastung entspricht. Der Richtlinientext ist wie zuvor beschrieben in Ihre YAML-Manifestdatei eingebettet und wird dem Agent frühzeitig während der CVM-Initialisierung bereitgestellt. Die Richtlinienanmerkung wird durch die Kubelet-, Container- und Kata-Shim-Komponenten des Systems "Vertrauliche Container" von AKS durchlaufen. 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 Ihres TCB sind, daher ist diese Richtlinie zunächst nicht vertrauenswürdig. Die Vertrauenswürdigkeit der Richtlinie muss über den Remotenachweis festgelegt werden, wie im folgenden Abschnitt beschrieben.
Einrichten der Vertrauensstellung im Richtliniendokument
Vor dem Erstellen des Pod CVM berechnet der Kata-Shim den SHA256-Hash des Richtliniendokuments und fügt diesen Hashwert an den TEE an. Diese Aktion erstellt eine starke Bindung zwischen dem Inhalt der Richtlinie und dem CVM. Dieses TEE-Feld kann später nicht von der software geändert werden, die innerhalb des CVM oder außerhalb davon ausgeführt wird.
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übereinstimmung erkannt wird.
Vor der Verarbeitung vertraulicher Informationen müssen Ihre Workloads Remotenachweisschritte ausführen, um allen vertrauenden Parteien zu beweisen, dass die Workload mit den erwarteten Versionen der TEE-, Betriebssystem-, Agent-, OPA- und Stammdateisystemversionen ausgeführt wird. Der Nachweis wird in einem Container implementiert, der innerhalb des CVM ausgeführt wird, der signierte Nachweise von der AMD SEV-SNP-Hardware abruft. Eines der Felder aus dem Nachweisnachweis ist das weiter oben beschriebene Feld für den Richtlinienhash-TEE. 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 zur Kata- und CoCo-Community beigetragen, den Agentcode, der für die Überprüfung der Richtlinie für jeden Agent ttrpc-API-Aufruf verantwortlich ist. Bevor Sie die Aktionen ausführen, die der API entsprechen, verwendet der Agent die OPA REST-API, um zu überprüfen, ob die Richtlinienregeln und Daten den Aufruf zulassen oder blockieren.