Eine Arbeitslast wird von einem Arbeitslastautor erstellt und verarbeitet die vertraulichen Daten, mit denen Datenmitbearbeiter arbeiten möchten.
Ein Autor einer Arbeitslast muss die folgenden Ressourcen zusammenstellen, um eine Arbeitslast zu erstellen:
Eine Anwendung zur Verarbeitung der vertraulichen Daten. Sie können Ihre Anwendung in einer beliebigen Sprache schreiben, sofern Sie ein containerisiertes Image erstellen, das sie unterstützt.
Ein containerisiertes Image, in dem die Anwendung mit Docker verpackt wird.
Ein Repository in Artifact Registry, in dem das Docker-Image gespeichert werden soll.
Startrichtlinien, die für das Container-Image festgelegt sind und steuern, wie eine Arbeitslast ausgeführt werden kann, und die Möglichkeiten eines böswilligen Arbeitslastbearbeiters einschränken.
Zur Bereitstellung der Arbeitslast wird eine Confidential VM von einem Arbeitslastoperator auf Grundlage des Confidential Space-Images ausgeführt. Dadurch wird das containerisierte Image aus Artifact Registry abgerufen und ausgeführt.
Datenbearbeiter müssen die Attestierungen einer Arbeitslast validieren, bevor sie auf ihre Daten zugreifen können.
Hinweise
Das Erstellen einer Arbeitslast für Confidential Space umfasst mehr als nur Code und Debugging. Außerdem müssen Sie mit den Datenbearbeitern sprechen, um ihre Anforderungen zu ermitteln, Ihre Umgebung einrichten, Ihren Code in ein containerisiertes Image verpacken und mit einem Arbeitslast-Betreiber zusammenarbeiten, um sicherzustellen, dass alles richtig bereitgestellt wird.
Mit den Mitbearbeitern sprechen
Bevor Sie mit dem Schreiben Ihrer Anwendung beginnen, müssen Sie mit Ihren Datenmitarbeitern über die privaten Daten sprechen, an denen Sie arbeiten sollen. Sie können beispielsweise folgende Fragen stellen:
Welche Organisations-IDs sind beteiligt?
Welche Projektnummern sind beteiligt?
Auf welche Google Cloud -Ressourcen muss ich zugreifen und wie lauten ihre IDs und Namen?
Gibt es Ressourcen, auf die ich zugreifen muss, die nicht vom IAM von Google Cloudverwaltet werden?
Wie sollte die Anwendung die privaten Daten vergleichen und verarbeiten?
In welchem Format sollte die Ausgabe sein?
Wo sollte die Ausgabe gespeichert werden und sollte sie verschlüsselt werden?
Sehen alle Mitbearbeiter dasselbe Ergebnis oder sind die Ergebnisse für jeden Nutzer individuell?
Außerdem kann es sein, dass jeder Datenmitarbeiter spezifische Datenschutzanforderungen hat, die Sie erfüllen müssen. Es ist äußerst wichtig, dass durch eine Arbeitslast keine privaten Daten offengelegt werden.
Confidential Space-Lösung erstellen
Es ist hilfreich, zwei oder mehr Projekte mit den entsprechenden Berechtigungen als Testumgebung einzurichten, wie in Erste Confidential Space-Umgebung erstellen beschrieben. Achten Sie darauf, die Projektkonfigurationen der Datenmitbearbeiter so gut wie möglich nachzuahmen. So können Sie Erfahrungen mit projektübergreifenden Berechtigungen sammeln und die benötigten Daten aus bestimmten Google Cloud -Ressourcen abrufen. Außerdem können Sie sich ein Bild von den Rollen des Arbeitslastbearbeiters und des Datenbearbeiters und ihren Aufgaben machen.
In der frühen Bauphase sollten Sie die folgenden Praktiken beachten:
Begrenzen Sie die Attestierungsbestätigung, wenn Sie als Datenbearbeiter arbeiten, um die Entwicklungsgeschwindigkeit zu erhöhen.
Wenn Sie als Arbeitslastoperator arbeiten, verwenden Sie beim Bereitstellen der Arbeitslast das Debug-Image für Confidential Space anstelle des Produktions-Images. So haben Sie mehr Möglichkeiten, Probleme mit der Arbeitslast zu beheben.
Wenn Ihre Anwendung ausgereift ist und ihr Status vorhersehbarer wird, können Sie Ihre Lösung mithilfe von Attestationsvalidierung und Startrichtlinien immer stärker sperren und zum Produktions-Image für den Confidential Space wechseln.
Nachdem Sie Ihre Arbeitslast in Ihrer Testumgebung richtig eingerichtet haben, können Sie zu Tests in den Projekten Ihrer Datenmitarbeiter mit echten Ressourcen, aber fiktiven Daten wechseln, um den Datenmitarbeitern zu zeigen, wie alles funktioniert. An diesem Punkt können Sie mit einem unabhängigen Arbeitslast-Betreiber zusammenarbeiten.
Wenn alles funktioniert und die Ausgabe wie erwartet ist, können Sie mit Tests an Produktionsdaten beginnen. Sobald die Tests abgeschlossen sind und alle Beteiligten die Ergebnisse genehmigt haben, kann die Arbeitslast in Produktion genommen werden.
Vorsicht bei der Ausgabe
Beim Testen Ihres Codes kann es verlockend sein, Fehler zu beheben, indem Sie auf STDOUT oder STDERR drucken. Achten Sie dabei darauf, dass keine privaten Daten offengelegt werden, die andere Parteien durch Zugriff auf Protokolle lesen könnten. Bevor Ihr Code in der Produktionsumgebung ausgeführt wird, sollten Sie dafür sorgen, dass nur das absolut Notwendige ausgegeben wird.
Dasselbe gilt für die endgültige Ausgabe. Stellen Sie nur ein Endergebnis bereit, das die Privatsphäre und Vertraulichkeit der ursprünglichen Daten nicht beeinträchtigt.
Containerisiertes Image mit Docker erstellen
Anwendungen müssen in einem von Docker erstellten containerisierten Image verpackt und in Artifact Registry gespeichert werden. Wenn eine Arbeitslast bereitgestellt wird, wird das Docker-Image vom Image des Confidential Space aus dem Artifact Registry-Repository abgerufen und ausgeführt. Die Anwendung kann dann mit den entsprechenden Projektressourcen arbeiten.
Beachten Sie beim Erstellen Ihres Docker-Images Folgendes:
Laufwerks- und Speicherlimits
In Confidential Space wird die Größe der zustandserhaltenden Partition des Bootlaufwerks automatisch angepasst, wenn größere Bootlaufwerkgrößen verwendet werden. Die Partitionsgröße entspricht ungefähr der Größe des Bootlaufwerks abzüglich 5 GB.
Im Rahmen des Integritätsschutzes für das Dateisystem von Confidential Space speichert Confidential Space Laufwerkintegritäts-Tags im Arbeitsspeicher. Dies führt zu einem Arbeitsspeicher-Overhead von etwa 1% pro Laufwerkbyte. Ein Laufwerk mit 100 GB benötigt beispielsweise 1 GB Arbeitsspeicher und ein Laufwerk mit 10 TB 100 GB Arbeitsspeicher.
Achten Sie darauf, die Arbeitsspeicherlimits der VM einzuhalten. Der Auslagerungsbereich ist auf Confidential Space-VMs deaktiviert. Das bedeutet, dass eine übermäßige Speichernutzung die Arbeitslast abstürzen lassen kann. Achten Sie darauf, dass die ausgewählte Maschine neben dem Overhead für die Laufwerkintegrität auch die Arbeitsspeichernutzung Ihrer Arbeitslast unterstützt.
Abgelaufene OIDC-Tokens
Beim Starten der Arbeitslast wird ein OIDC-Token bereitgestellt. Es enthält bestätigte Attestationsansprüche für die VM Ihrer Arbeitslast und wird im Arbeitslastcontainer unter /run/container_launcher/attestation_verifier_claims_token gespeichert. Das Token läuft nach 60 Minuten ab.
Wenn das Token abläuft, wird im Hintergrund eine Aktualisierung mit exponentiellem Backoff versucht, bis dies erfolgreich ist. Wenn eine Aktualisierung fehlschlägt (z. B. aufgrund von Netzwerkproblemen oder einem Ausfall des Attestierungsdienstes), muss Ihr Workload-Code diesen Fehler beheben können.
Sie können einen Fehler beim Aktualisieren des Tokens auf eine der folgenden Arten behandeln:
Ignoriere das abgelaufene Token, sofern es nach der ersten Verwendung nicht mehr benötigt wird.
Warten Sie, bis das abgelaufene Token erfolgreich aktualisiert wurde.
Beenden Sie die Arbeitslast.
In-Memory-Scratch-Bereitstellungen
Confidential Space unterstützt das Hinzufügen von Arbeitsspeicher-Scratch-Bereichen. Dabei wird der verfügbare Arbeitsspeicher der Confidential Space-VM verwendet. Da der Scratch-Space den Arbeitsspeicher der Confidential VM verwendet, hat er dieselben Integritäts- und Vertraulichkeitseigenschaften wie die Confidential VM.
Mit tee-dev-shm-size können Sie die Größe des /dev/shm-Speicherplatzes für die Arbeitslast erhöhen.
Die Größe von /dev/shm wird in KB angegeben.
Mit tee-mount können Sie mithilfe von semikolons getrennten Konfigurationen tmpfs-Dateisysteme im laufenden Container angeben. type und source sind immer tmpfs. destination ist der Bereitstellungspunkt, der mit der tee.launch_policy.allow_mount_destinations-Startrichtlinie interagiert. Optional können Sie die Größe von tmpfs in Byte angeben. Die Standardgröße beträgt 50% des VM-Arbeitsspeichers.
Eingehende Ports
Standardmäßig werden Confidential Space-VMs mit einer Firewallregel betrieben, die alle eingehenden Ports blockiert. Wenn Sie eine Confidential Space-Image-Version von 230600 oder höher verwenden, können Sie beim Erstellen Ihres Arbeitslast-Images in Dockerfile eingehende Ports angeben, die geöffnet bleiben sollen.
Wenn Sie Ports öffnen möchten, fügen Sie das Schlüsselwort EXPOSE mit der Portnummer, die offen bleiben soll, und einem optionalen Protokoll von tcp oder udp der Dockerfile hinzu. Wenn Sie das Protokoll für einen Port nicht angeben, sind sowohl TCP als auch UDP zulässig. Hier ist ein Beispiel für Dockerfile, mit dem eingehende Ports preisgegeben werden:
FROM alpine:latest
EXPOSE 80
EXPOSE 443/tcp
EXPOSE 81/udp
WORKDIR /test
COPY salary /test
ENTRYPOINT ["/test/salary"]
CMD []
Je nach verwendetem Basis-Image sind einige Ports möglicherweise bereits freigegeben. Ihr Dockerfile stellt nur zusätzliche Ports bereit. Es kann keine Ports blockieren, die bereits vom Basis-Image geöffnet wurden.
Arbeitslast-Betreiber müssen dafür sorgen, dass die freigegebenen Ports in ihrer VPC-Firewall geöffnet sind, bevor sie die Arbeitslast ausführen. Die Portnummern können vom Autor der Arbeitslast angegeben oder aus den Docker-Image-Informationen abgerufen werden.
Bei Verwendung der Metadatenvariablen tee-container-log-redirect werden freigegebene Ports in der Console protokolliert und an Cloud Logging weitergeleitet.
Startrichtlinien
Startrichtlinien überschreiben die von Arbeitslastbearbeitern festgelegten VM-Metadatenvariablen, um schädliche Aktionen einzuschränken. Der Autor einer Arbeitslast kann beim Erstellen seines Container-Images Richtlinien mit einem Label festlegen.
Beispielsweise in einem Dockerfile:
LABEL "tee.launch_policy.allow_cmd_override"="true"
In einer Bazel-BUILD-Datei:
container_image(
...
labels={"tee.launch_policy.allow_cmd_override":"true"}
...
)
Die verfügbaren Startrichtlinien finden Sie in der folgenden Tabelle:
| Policy | Typ | Beschreibung |
|---|---|---|
|
Interagiert mit:
|
Boolesch (Standardwert: false) |
Bestimmt, ob das im Dockerfile des Arbeitslastcontainers angegebene
CMD durch einen Arbeitslastoperator mit dem Metadatenwert
tee-cmd überschrieben werden kann.
|
|
Interagiert mit:
|
Kommagetrennter String |
Ein kommagetrennter String mit zulässigen Umgebungsvariablennamen, die von einem Workload-Betreiber mit
tee-env-ENVIRONMENT_VARIABLE_NAME-Metadatenwerten festgelegt werden dürfen.
|
|
Interagiert mit:
|
Durch Doppelpunkte getrennter String |
Ein durch Doppelpunkte getrennter String zulässiger Bereitstellungsverzeichnisse, die der Arbeitslastoperator mit Beispiel: |
|
Interagiert mit:
|
Definierter String |
Bestimmt, wie das Logging funktioniert, wenn
Gültige Werte:
|
|
Interagiert mit:
|
Definierter String |
Bestimmt, wie die Überwachung der Arbeitsspeichernutzung funktioniert, wenn
Gültige Werte:
|
Mehrere Arbeitslastausführungen
Damit eine saubere Umgebung gewährleistet ist, muss eine VM neu gestartet werden, um eine Arbeitslast neu zu starten. Dadurch wird das VM-Laufwerk mit einem sitzungsspezifischen Schlüssel verschlüsselt, um den Angriffsvektor zu beheben, bei dem ein Arbeitslast-Image auf dem Laufwerk geändert wird, nachdem es heruntergeladen und gemessen wurde.
Außerdem erhöht sich der Overhead, z. B. durch die Bootzeit und das Abrufen des Arbeitslast-Images bei jeder Ausführung der Arbeitslast. Wenn diese Overheads die Leistung Ihrer Arbeitslast zu stark beeinträchtigen, können Sie einen Neustart der Arbeitslast in die Arbeitslast selbst codieren, was jedoch Ihr Risikoprofil erhöht.
Reproduzierbare Container-Images
Wenn Sie ein Container-Image auf reproduzierbare Weise erstellen, kann das das Vertrauen zwischen den Parteien stärken. Sie können mit Bazel reproduzierbare Images erstellen.
Ressourcen, die nicht über das IAM von Google Cloud verwaltet werden
Wenn Sie auf Ressourcen zugreifen möchten, die nicht über das IAM von Google Cloud verwaltet werden, muss für Ihre Arbeitslast eine benutzerdefinierte Zielgruppe angegeben werden.
Weitere Informationen finden Sie unter Auf Ressourcen zugreifen, die nicht von Google Cloud IAM verwaltet werden.
Signierte Container-Images
Sie können ein Container-Image mit einem öffentlichen Schlüssel signieren, den ein Datenbearbeiter dann für die Attestierung verwenden kann, anstatt in seiner WIP-Richtlinie einen Image-Digest anzugeben.
Das bedeutet, dass Datenbearbeiter ihre WIP-Richtlinien nicht jedes Mal aktualisieren müssen, wenn eine Arbeitslast aktualisiert wird. Die Arbeitslast kann weiterhin ungehindert auf geschützte Ressourcen zugreifen.
Sie können Sigstore Cosign verwenden, um das Container-Image zu signieren. Damit Confidential Space die Signaturen abrufen kann, müssen Arbeitslastoperatoren die Signaturinformationen der Metadatenvariablen tee-signed-image-repos hinzufügen, bevor sie die Arbeitslast bereitstellen.
Während der Laufzeit werden Signaturen zur Überprüfung an den Attestierungsservice für Confidential Space gesendet. Der Attestierungsdienst gibt ein Attestierungsanspruchstoken zurück, das die bestätigten Signaturansprüche enthält. Hier ein Beispiel für einen Anspruch auf Signatur:
"image_signatures": [
{
"key_id": "hexadecimal-sha256-fingerprint-public-key1",
"signature": "base64-encoded-signature",
"signature_algorithm": "RSASSA_PSS_SHA256"
},
{
"key_id": "hexadecimal-sha256-fingerprint-public-key2",
"signature": "base64-encoded-signature",
"signature_algorithm": "RSASSA_PSS_SHA256",
},
{
"key_id": "hexadecimal-sha256-fingerprint-public-key3",
"signature": "base64-encoded-signature",
"signature_algorithm": "RSASSA_PSS_SHA256",
}
],
Informationen zum Konfigurieren der Signatur von Container-Images finden Sie im Codelab zu signierten Container-Images.