Zum Hauptinhalt springen
Version: Weekly Build

Confidential Managed Services

title: "Confidential Managed Services" slug: /confidential-compute/running-confidential-services/confidential-managed-services sidebar_position: 3​

Confidential Managed Services

hinweis

Nicht jede Codesphere-Instanz bietet Confidential Compute an. Frag den Codesphere-Administrator, ob Confidential Compute auf der jeweiligen Instanz verfügbar ist. Siehe Voraussetzungen.

Managed Services wie Datenbanken enthalten oft die sensibelsten Daten. Im Confidential-Modus läuft jede Service-Instanz in einer Confidential Micro-VM, speichert ihre Daten auf verschlüsselten Volumes und kommuniziert über den Service Mesh. Ihre Secrets stammen aus dem Trustee Service Vault, sodass Codesphere sie niemals zu Gesicht bekommt.

Voraussetzungen​

Unterschiede zu regulären Managed Services​

  • Secrets stammen aus dem Trustee Service Vault. Secrets werden beim Erstellen des Service nicht eingegeben. Stattdessen werden Vault-Pfade angegeben, und der Service liest die Werte nach der Attestierung aus dem Trustee Service Vault aus. Codesphere speichert, zeigt oder ändert sie nicht.
  • Nur Services derselben Workload können sich verbinden. Ein Confidential Managed Service akzeptiert nur Verbindungen von Confidential Services mit derselben Workload-ID in derselben Resource Group, zum Beispiel den Services einer Confidential Landscape.
  • Der Confidential-Modus wird bei der Erstellung festgelegt. Ein bestehender Service kann nicht nachträglich in einen Confidential Service umgewandelt werden oder umgekehrt. Auch die Workload-ID und die Adresse des Trustee Service können nicht geändert werden. Um zu wechseln, muss ein neuer Service erstellt und die Daten manuell migriert werden, zum Beispiel durch Export aus dem alten und Import in den neuen Service.
  • Langsamerer Start und höherer Speicherbedarf. Jede Instanz startet eine Micro-VM und durchläuft die Attestierung, bevor sie startet. Siehe Einschränkungen und Fallstricke.

Provider-Unterstützung prüfen​

Aktuell können folgende Provider im Confidential-Modus genutzt werden:

  • PostgreSQL unterstützt den Confidential-Modus.
  • Object Storage (S3) hat keinen Confidential-Modus, die Vertraulichkeit der Daten kann jedoch durch Verschlüsselung sichergestellt werden. Siehe Object Storage (S3).

Um einen Provider zu prüfen, öffne dessen Detailseite über Start setup auf der jeweiligen Karte im Katalog. Provider, die den Confidential-Modus unterstützen, listen Confidential Compute unter ihren Funktionen auf.

In der API liefert der Endpunkt /managed-services/providers die Funktionen jedes Providers zurück. Provider mit Confidential-Modus-Unterstützung haben confidentialCompute: true.

Object Storage (S3)​

Object Storage hat keinen Confidential-Modus. Buckets werden außerhalb der Confidential Micro-VMs gespeichert. Um deren Inhalte vertraulich zu halten, verschlüssel sie mit einem Schlüssel, den nur die eigene Confidential Workload kennt:

  1. Speichere den Schlüssel im Trustee Service Vault, zum Beispiel als encryptionKey (openssl rand 32 | base64).
  2. Lies ihn im Service aus, zum Beispiel mit ${{ vault.encryptionKey }}.
  3. Verwende den Schlüssel mit einer der unten beschriebenen Methoden.

Die Access- und Secret-Keys des Buckets müssen nicht im Vault liegen. Ohne den Verschlüsselungsschlüssel ermöglichen sie nur Zugriff auf verschlüsselte Daten. Geht der Schlüssel verloren, können die Daten nicht wiederhergestellt werden.

Serverseitige Verschlüsselung mit kundenseitig bereitgestellten Schlüsseln (SSE-C): Der Client sendet den Schlüssel mit jeder Anfrage. Das Object-Storage-Gateway läuft in Confidential Pods, verschlüsselt das Objekt dort vor der Speicherung und behält den Schlüssel nicht. Es funktioniert mit jedem S3-Client, der SSE-C unterstützt. SSE-C benötigt den HTTPS-Endpunkt https://rgw-load-balancer.rook-ceph.svc.cluster.local.

aws s3 cp report.pdf s3://my-bucket/ \
  --endpoint-url https://rgw-load-balancer.rook-ceph.svc.cluster.local \
  --sse-c AES256 --sse-c-key fileb://<(echo "$ENCRYPTION_KEY" | base64 -d)

Zum Lesen des Objekts sind dieselben --sse-c-Flags erforderlich.

Clientseitige Verschlüsselung (CSE): Der Client verschlüsselt die Daten vor dem Hochladen, sodass der Object Storage ausschließlich verschlüsselte Daten sieht. Nur Clients, die das Verschlüsselungsformat kennen, können sie lesen. Zum Beispiel mit einem rclone crypt-Remote auf Basis eines S3-Remotes namens s3:

rclone config create secure crypt remote s3:my-bucket \
  password "$(rclone obscure "$ENCRYPTION_KEY")"
rclone copy ./data secure:

Erstellen eines Confidential Managed Service​

Ein Confidential Managed Service wird größtenteils wie ein regulärer Service erstellt. Der Unterschied liegt in der Handhabung der Secrets. Diese werden im Trustee Service Vault gespeichert, nicht in Codesphere. Statt beim Erstellen des Service Secret-Werte einzugeben, werden die Vault-Pfade angegeben, die darauf verweisen.

Erstelle den Service wie unter Services bereitstellen beschrieben, mit folgenden Änderungen:

  1. Aktiviere unter Advanced Settings die Option Confidential Compute.
  2. Gib die Workload-ID unter vHSM Workload ID ein.
  3. Gib die Adresse des Trustee Service unter vHSM Address ein.
  4. Gib die Vault-Pfade der Secrets ein.

Managed Services in Confidential Landscapes​

In einer Landscape definierte Managed Services werden automatisch im Confidential-Modus erstellt, wenn die Landscape in einem Confidential Workspace läuft. Sie verwenden dieselbe Workload-ID und denselben Trustee Service wie der Workspace. Es gibt keine separate Einstellung in der ci.yml.

Wie bei eigenständigen Confidential Managed Services werden die Vault-Pfade der Secrets angegeben. Der Service liest die Werte nach der Attestierung aus dem Trustee Service Vault aus.