Confidential Computing nutzt eine Trusted Execution Environment (TEE), um den verwendeten Speicher zu schützen. Dadurch wird die Verschlüsselung von Daten im Ruhezustand, bei der Übertragung und bei Verwendung sichergestellt. Confidential Containers (CoCo) kombinieren die TEE- mit Kubernetes-Deployments. Das Deployment einer TEE auf Pod-Ebene ermöglicht eine starke Isolierung von Workloads, nicht nur von anderen Workloads auf dem Cluster, sondern auch von Cluster-Administrationsteams.

Die Herausforderung bei Confidential Containers besteht in den ersten Schritten. Die Entscheidung, einen Pod in einem Confidential Container bereitzustellen, erfordert lediglich eine einzige Zeilenänderung im Pod-Manifest. Für den Einstieg müssen Sie jedoch einige Komponenten erfolgreich zusammen bereitstellen, idealerweise in mehreren Clustern. Red Hat hat vor kurzem die Unterstützung für Confidential Containers auf Microsoft Azure in Red Hat OpenShift Sandbox Container Operator v1.9 und höher sowie die Unterstützung für Remote Attestation mit dem Red Hat Build von Trustee veröffentlicht.

Dieser Blog soll erläutern, wie sich mit Validated Patterns 3 Ziele erreichen lassen:

1. Vereinfachter Einstieg in Confidential Containers (CoCo) mit OpenShift Sandboxed Containers Operator und Red Hat Build von Trustee auf Azure
2. Bereitstellung einer konsistenten und deklarativen Basis für CoCo, um Deployments nach Best Practices zu ermöglichen
3. Demonstration des Bereitstellens von Anwendungen mit CoCo

Überblick über Validated Patterns 

Validated Patterns sind lebendige Code-Architekturen für verschiedene Use Cases für Multi Clouds und Hybrid Clouds. Die Patterns werden getestet und, wenn sie ausgereift sind, in das CI-System (Continuous Integration) von Red Hat eingefügt. So stellen wir sicher, dass wir Tests mit der aktuellsten Version von Operatoren, OpenShift-Releases und in mehreren Public Cloud-Umgebungen durchführen.

Die einzelnen Validated Pattern Repositories von Red Hat zeigen einen Business Use Case in Form von Kubernetes-Ressourcen (Helm Charts, Kustomize und Primitive Objects), die einen Hybrid Cloud Stack deklarativ und umfassend beschreiben, und zwar von Services bis hin zur unterstützenden Infrastruktur. Validierte Patterns ermöglichen komplexe, hochgradig reproduzierbare Deployments und sind ideal für den Betrieb dieser Deployments in großem Umfang mithilfe von GitOps-Betriebspraktiken.

Gründe für die Nutzung von Validated Patterns 

Das Deployment komplexer Geschäftslösungen umfasst mehrere Schritte. Werden die einzelnen Schritte nachlässig ausgeführt, kann dies zu potenziellen Fehlern oder Ineffizienzen führen. Validated Patterns lösen dieses Problem, indem sie einen vorvalidierten, automatisierten Deployment-Prozess bieten:

• Verwendung eines GitOps-Modells, um den Use Case als Code bereitzustellen.
• Funktion als Proof of Concept (PoC), der an eine bestimmte Anforderung angepasst ist und von Ihnen zu einem echten Deployment weiterentwickelt werden kann.
• Hohe Reproduzierbarkeit, die sich ideal für den Einsatz in großem Umfang eignet.
• Validierte Patterns, offen für die Zusammenarbeit. Einzelne Personen können Verbesserungen vorschlagen, zu ihnen beitragen oder sie nutzen, da sich die Git-Repositories im Upstream befinden.
• Validated Patterns können an Ihre spezifischen Anforderungen angepasst werden. Wenn Sie eine Komponente austauschen möchten, wie etwa Ceph-Storage statt S3, können Sie einfach Abschnitte in der Konfiguration auskommentieren und ein anderes Repository hinzufügen.
• Es ist getestet. Sobald der Use Case zu einem Validated Pattern gemacht wurde, wird er in die CI von Red Hat aufgenommen und weiterhin in verschiedenen Produktversionen getestet, während das Pattern aktiv bleibt.

Validated Patterns sind eine Lösung nach dem Motto „Batterien inklusive“. Unabhängig davon, wo Sie das Patterns Framework verwenden, werden sowohl der Kern als auch eine konfigurierbare Reihe von Komponenten sofort einsatzbereit geliefert. Für diesen Artikel wurde ein Validated Pattern verwendet, um einen einfachen Einstieg in Confidential Containers zu schaffen.

Deployment eines Patterns

Die Website für Validated Patterns enthält eine ausführliche Dokumentation zur Verwendung von Validated Patterns. Best Practices erfordern:

1. Ein Git-Repository für das Pattern, beispielsweise ein Fork des Patterns. Validated Patterns verwenden GitOps, daher müssen Sie das verwendete Repository kontrollieren.
2. Ein Entwicklungs-Laptop mit installiertem oc, Git und Podman.
3. Einen leeren OpenShift Cluster, in dem der Pattern-Operator den Cluster managt.

Die Anforderungen wirken wie folgt zusammen:

Mit dieser Einrichtung „gehört“ dem Validated Pattern der Cluster, und Sie haben nur einen einzigen Ausgangspunkt.

Verwendung von Validated Patterns für Confidential Containers

Red Hat OpenShift Sandbox-Container basieren auf Kata Container und bieten die zusätzliche Möglichkeit, Confidential Containers auszuführen. Confidential Containers sind Container, die in einer isolierten Hardware-Enklave bereitgestellt werden, um Daten und Code von privilegierten Nutzenden wie Cloud- oder Cluster-Administrationsteams zu schützen. Das CNCF Confidential Containers-Projekt ist die Basis für die OpenShift CoCo-Lösung.

Confidential Computing trägt durch den Einsatz dedizierter, hardwarebasierter Lösungen zum Schutz Ihrer Daten während der Verwendung bei. Mithilfe von Hardware können Sie isolierte Umgebungen erstellen, deren Eigentümer Sie sind. So können Sie sich vor unbefugtem Zugriff oder Änderungen an den Daten Ihrer Workloads während der Ausführung schützen (verwendete Daten).

CoCo ermöglicht cloudnatives Confidential Computing durch die Nutzung einer Vielzahl von Hardwareplattformen und unterstützenden Technologien. CoCo zielt darauf ab, Confidential Computing auf Pod-Ebene zu standardisieren und seine Nutzung in Kubernetes-Umgebungen zu vereinfachen. So können Nutzende von Kubernetes CoCo-Workloads mithilfe vertrauter Workflows und Tools bereitstellen, ohne dass sie ein tiefes Verständnis der zugrunde liegenden Confidential Computing-Technologien benötigen.

Weitere Informationen finden Sie unter Erkundung der OpenShift-Lösung für Confidential Containers. 

Confidential Containers-Architektur 

Die Lösung für Confidential Containers von Red Hat basiert auf 2 wichtigen Operatoren:

• Red Hat OpenShift Confidential Containers: Eine Funktion, die Red Hat OpenShift Sandbox Containers Operator hinzugefügt wurde. Der Container-Operator ist für das Bereitstellen der Bausteine für die Verbindung von Workloads (Pods) und vertraulichen virtuellen Maschinen (CVM) verantwortlich, die innerhalb der von der Hardware bereitgestellten TEE ausgeführt werden.
• Remote Attestation: Der Red Hat Build von Trustee ist für das Deployment und Management des Key Broker Service (KBS) in einem Red Hat OpenShift Cluster verantwortlich.

Weitere Informationen finden Sie unter Einführung in Confidential Containers Trustee: Lösungsüberblick und Use Cases von Attestation Services.

CoCo verfügt in der Regel über 2 Umgebungen: eine vertrauenswürdige Zone und eine nicht vertrauenswürdige Zone. In diesen Zonen werden Trustee und der Sandbox-Container-Operator bereitgestellt: 

Worin besteht also die Herausforderung? Um dies zu verstehen, benötigen Sie Kenntnisse und spezifische Details zu Ihrer Cloud- oder On-Premise-Infrastruktur. Dabei sollten mehrere Fragen berücksichtigt werden, beispielsweise: In welcher Region befinden Sie sich? Welchen Chipsatz (Intel, AMD, IBM Power, s390) und welchen Hypervisor haben Sie als Ziel? 

Weitere Informationen zum Deployment von CoCo finden Sie unter Aspekte zum Deployment der Confidential Container-Lösung von Red Hat OpenShift.

Einführung in das Validated Pattern für Confidential Container

Das Ziel des Validated Pattern für Confidential Container besteht darin, den Einstieg zu erleichtern und zu verstehen, wie Confidential Containers bereitgestellt werden. Der Service verwendet die Validated Pattern-Architektur für:

1. Deployment der erforderlichen Operatoren für das Ausführen von CoCo
2. Konfiguration der peripheren Hintergrundkomponenten, einschließlich Zertifikate (mit Let's Encrypt, falls erforderlich)
3. Abstraktion der Nutzenden, die CoCo aus der Cloud auf dem Cluster bereitstellen,unter Verwendung von Tools wie Red Hat Advanced Cluster Manager
4. Deployment einer Vielzahl von Beispielanwendungen, um verschiedene Funktionen von Confidential Containers zu demonstrieren, einschließlich der Änderung von CoCo

Derzeit wird das Pattern auf Microsoft Azure in einem einzelnen Cluster bereitgestellt, wobei sämtliche Komponenten aus einem einzelnen validierten Pattern stammen (weitere Deployments werden in Zukunft hinzugefügt).

Funktionsweise

Wir nutzen den Validated Patterns Operator, um Argo CD bereitzustellen, und Argo CD stellt die zusätzlich erforderlichen Operatoren bereit. 

Das Problem besteht darin, dass die Konfigurations-Map Peer-Pods, einschließlich init-data und kata-policy, so konfiguriert sein muss, dass sie auf den Trustee Key Broker Service (KBS) verweist. Diese Informationen sind dynamisch und erfordern, dass Nutzende entweder die Azure-CLI verwenden oder auf das Azure-Portal zugreifen. Aus der Perspektive der Sicherheit und Transparenz sind init-data und kata-policy ebenfalls problematisch, da sie mit base64 serialisiert werden, bevor sie an eine ConfigMap übertragen werden. Dadurch ist es für Nutzende schwierig, den Status zu überprüfen.

Diese Probleme werden durch die Verwendung von Metadaten gelöst, die vom Validated Patterns Operator injiziert werden, sodass wir in unserer Anwendung einfach auf Informationen zum Cluster zugreifen können. Mit erweiterten Cluster-Manager-Richtlinien werden Informationen erfasst, die vom Cloud Controller-Manager definiert wurden, und damit sie in die entsprechenden Konfigurations-Maps und Secrets für den Sandbox-Container-Operator eingefügt werden.

Hashicorp Vault wird als KMS innerhalb des Clusters mit der Secrets-Konfiguration für Validated Patterns verwendet. So können Nutzende Vault von einer Entwicklungs-Workstation-Umgebung aus konsistent nutzen. Wir verwenden diese Option, um Secrets für Trustee bereitzustellen, die mit dem externen Secrets-Operator synchronisiert werden.

Die Kombination dieser Funktionen ermöglicht eine Installation mit einem einzigen Befehl und wird im Folgenden gezeigt: 

Anforderungen 

Derzeit sind wir auf Azure als Plattform beschränkt, wobei die simple Pattern-Topologie ein einzelner OpenShift-Cluster ist.

Nutzende können entweder einen Azure Red Hat OpenShift Cluster oder einen selbst gemanagten OpenShift Cluster auf Azure verwenden. Das Pattern enthält eine Dokumentation zur Verwendung von openshift-install zur Erstellung eines Clusters. Das Cluster- und Azure-Konto müssen Zugriff auf und Verfügbarkeit von Azure CVMs in der Region haben. Heute geht das Pattern von virtuellen Rechnern der Klasse DCasv5 für die Confidential Container aus, dies kann jedoch angepasst werden.

Die einzige zusätzliche Konfiguration, die für Azure erforderlich ist, ist das Deployment eines NAT-Gateways für das Workerknoten-Subnetz. Dies erfolgt automatisch.

Für die Entwicklungs-Workstation ist eine POSIX-Workstation (Mac OS oder Linux) mit installiertem oc und podman erforderlich.

Schritt-für-Schritt-Anleitungen

Es gibt nur 3 Schritte:

1. Erstellen eines Fork

Erstellen Sie zunächst einen Fork des GitHub-Repositorys für Validated Patterns in Ihrer Organisation. Beachten Sie, dass es aufgrund der Eventual Consistency von Argo CD nicht sicher ist, das Validated Patterns Repository direkt zu verwenden.

git clone https://github.com/(YOUR ORG}/coco-pattern.git

2. Generieren zufälliger Schlüssel

Generieren Sie als Nächstes die Baseline-Secrets. Das Pattern enthält Skripte zum Generieren von zufälligen Schlüsseln:

sh scripts/gen-secrets.sh

3. Installieren

Melden Sie sich mit oc login beim Cluster an und führen Sie die Pattern-Installation aus:

./pattern.sh make install

Das ist alles! Warten Sie, bis das System online ist, und prüfen Sie dann die bereitgestellten Anwendungen.

Prüfung der bereitgestellten Anwendungen

Das Pattern stellt eine Argo CD-Instanz mit dem Namen Simple ArgoCD im Feldmenü 9 in der OpenShift-Webkonsole bereit. Eine Vielzahl von Anwendungen werden bereitgestellt. Die beiden wichtigsten zu berücksichtigenden Anwendungen sind hello-openshift und kps-access.

Die Anwendung hello-openshift stellt eine Webanwendung dreimal bereit: 

• Als Standard-Pod
• Als Kata-Pod, bei dem die Agent-Konfiguration absichtlich überschrieben wurde, damit Nutzende den Pod ausführen können
• Als „sichere“ Anwendung mit aktivierter CoCo-Härtung

Die Anwendung kps-access ist eine einfache Demonstration zum Abrufen eines Secrets von Trustee mithilfe eines init-Containers. Mit dem KBS-Zugriff können Sie über die Web-API auf das Secret zugreifen, sodass Sie sehen können, wie Änderungen im Secret durch das System weitergeleitet werden. Diese Init-Container-Methode zum Abrufen von Secrets ist eine praktische Methode, um die Sicherheit bestehender Anwendungen zu erhöhen, da Sie dies ohne Trustee bei der Entwicklung von Code durchführen können.

Sicherheitsaspekte beim Deployment von CoCo-Patterns 

Bei Confidential Containers geht es in erster Linie um Sicherheit. Daher ist es wichtig, die Sicherheitslage des Validate Pattern für Confidential Containers zu berücksichtigen. Für dieses Pattern gibt es 2 grundlegende Überlegungen:

• Das aktuelle Pattern verwendet einfache Referenzwerte. Wir empfehlen Ihnen, sich über den Ablauf der RATS-Attestation zu informieren und Richtlinien zu entwickeln, die Ihren Sicherheitsanforderungen und dem Risikoprofil eines Systems entsprechen.
• Abtrennen des Trustee-Deployments. Im Zusammenhang mit dem ersten Punkt basiert der Attestation Service von Trustee auf dem Prinzip, dass er in einer anderen und vertrauenswürdigen Sicherheitszone ausgeführt wird. Im Idealfall handelt es sich um eine andere Umgebung, wie etwa eine On-Premise-Umgebung oder bei einem anderen Cloud-Anbieter.

Das folgende Diagramm zeigt die Architektur für das Deployment von Trustee in einer abgetrennten Umgebung mit dem Validated Pattern für Confidential Container:

CoCo-Patterns in der Zukunft 

Das CoCo Validated Pattern ist für den Einstieg ausreichend. Sein Schwerpunkt liegt darauf, dass Sie in einem einzelnen Cluster und einer einzelnen Umgebung so erfolgreich sind, dass Sie mit den Tests beginnen können. Unser unmittelbarer Fokus liegt darauf, dies mit praktischeren Beispielen zu erweitern, damit Sie Confidential Containers weiterhin nutzen können.

Wir möchten Multi Cluster-Hub-and-Spoke-Deployments unterstützen, damit Trustee mit Red Hat Advanced Cluster Management im Hub bereitgestellt werden kann und die Confidential Workloads auf den Spoke-Clustern ausgeführt werden.

Wir möchten auch praktische Beispiele für die Verwendung von Trustee beim Secret-Management bieten. Die Beispiele sind bisher einfach. Unsere Prioritäten für die zukünftige Entwicklung sind die Verwaltung von Storage-Verschlüsselung innerhalb einer TEE und die Secret-Initialisierung für Anwendungen, die Trustee und die VPN-Konfiguration nicht kennen.

Außerdem möchten wir andere Umgebungen für das Deployment von CoCo und Trustee unterstützen, damit das Vertrauen auf Ressourcen vor Ort oder bei mehreren Cloud-Serviceanbietern verteilt werden kann.

Zusammenfassung 

Das Validated Pattern für Confidential Containers bietet einen einfachen Mechanismus für den Einstieg in CoCo. Es ist ein hervorragender Mechanismus, um mit Argo CD zu experimentieren und Ihre eigenen eigenständigen Anwendungen in einem einzigen Repository bereitzustellen und dabei einen standardisierten App of App GitOps-Ansatz zu nutzen. Wie bereits erwähnt, kann der Einstieg so einfach sein wie git clone und make install.