Eine Arbeitslast wird von einem Arbeitslastautor erstellt und verarbeitet die vertraulichen Daten, mit denen Datenmitbearbeiter arbeiten möchten.
Ein Arbeitslastautor 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 diese Sprache unterstützt.
Ein Container-Image, um die Anwendung mit Docker zu verpacken.
Ein Repository in Artifact Registry zum Speichern des Docker-Images.
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 Arbeitslastoperators einschränken.
Zum Bereitstellen 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.
Daten-Mitbearbeiter müssen die Attestierungen einer Arbeitslast validieren, bevor sie auf ihre Daten zugreifen können.
Hinweise
Das Schreiben einer Arbeitslast für Confidential Space umfasst mehr als nur Code und Debugging. Sie müssen sich auch mit Datenmitarbeitern austauschen, um ihre Anforderungen zu ermitteln, Ihre Umgebung einzurichten, Ihren Code in einem Container-Image zu verpacken und mit einem Workload-Operator zusammenarbeiten, um sicherzustellen, dass alles korrekt bereitgestellt wird.
Mit den Datenmitarbeitern sprechen
Bevor Sie mit dem Schreiben Ihrer Anwendung beginnen, müssen Sie sich mit Ihren Datenpartnern darüber unterhalten, welche privaten Daten sie Ihnen zur Verfügung stellen möchten. Hier einige Beispielfragen:
Welche Organisations-IDs sind betroffen?
Welche Projektnummern sind betroffen?
Auf welche Google Cloud Ressourcen muss ich zugreifen und welche IDs und Namen haben sie?
Gibt es Ressourcen, auf die ich zugreifen muss, die nicht von Google CloudIAM verwaltet werden?
Wie sollte die Anwendung die privaten Daten vergleichen und verarbeiten?
In welchem Format sollte die Ausgabe erfolgen?
Wo soll die Ausgabe gespeichert werden und soll sie verschlüsselt werden?
Sehen alle Datenmitarbeiter dasselbe Ergebnis oder sind die Ausgaben für jeden einzigartig?
Außerdem hat jeder Datenpartner möglicherweise eigene Datenschutzanforderungen, die Sie erfüllen müssen. Es ist von entscheidender Bedeutung, dass durch einen Arbeitslast keine privaten Daten offengelegt werden.
Confidential Space-Lösung erstellen
Es ist sinnvoll, zwei oder mehr Projekte mit den entsprechenden Berechtigungen als Testumgebung einzurichten, wie in Erste Confidential Space-Umgebung erstellen beschrieben. Versuchen Sie, die Projekteinrichtung der Daten-Mitbearbeiter so gut wie möglich nachzubilden. So können Sie sich mit projektübergreifenden Berechtigungen vertraut machen und die benötigten Daten aus bestimmten Google Cloud Ressourcen abrufen. Außerdem erhalten Sie einen Überblick über die Rollen „Workload-Operator“ und „Daten-Mitwirkender“ und ihre Verantwortlichkeiten.
In der frühen Entwicklungsphase ist es hilfreich, die folgenden Empfehlungen zu beachten:
Wenn Sie als Datenbearbeiter arbeiten, sollten Sie die Bestätigungsvalidierung aus Gründen der Entwicklungsgeschwindigkeit auf ein Minimum beschränken.
Wenn Sie als Arbeitslastoperator arbeiten, verwenden Sie beim Bereitstellen der Arbeitslast das Confidential Space-Debug-Image anstelle des Produktions-Images. So haben Sie mehr Möglichkeiten, Fehler in der Arbeitslast zu beheben.
Wenn Ihre Anwendung ausgereifter ist und ihr Status vorhersehbarer wird, können Sie Ihre Lösung zunehmend mit Bestätigungsvalidierung und Startrichtlinien sichern und zum Confidential Space-Produktions-Image wechseln.
Nachdem Ihre Arbeitslast in Ihrer Testumgebung korrekt funktioniert, können Sie mit dem Testen in den Projekten Ihrer Datenpartner mit echten Ressourcen, aber gefälschten Daten fortfahren, damit Sie den Datenpartnern zeigen können, wie alles funktioniert. Zu diesem Zeitpunkt können Sie mit einem unabhängigen Arbeitslastoperator zusammenarbeiten.
Wenn alles funktioniert und die Ausgabe wie erwartet ist, können Sie mit dem Testen mit Produktionsdaten beginnen. Nach Abschluss der Tests und der Genehmigung der Ergebnisse durch alle Beteiligten kann der Arbeitslast in der Produktion eingesetzt werden.
Vorsicht bei der Ausgabe
Beim Testen von Code kann es verlockend sein, Fehler zu beheben, indem Sie in STDOUT oder STDERR ausgeben. Wenn Sie sich dafür entscheiden, achten Sie darauf, dass Sie keine privaten Daten preisgeben, die andere Parteien durch Zugriff auf Logs lesen könnten. Bevor Ihr Code in der Produktion ausgeführt wird, sollten Sie darauf achten, dass er nur die unbedingt erforderlichen Informationen ausgibt.
Dasselbe gilt für die endgültige Ausgabe. Geben Sie nur ein Endergebnis an, das die Vertraulichkeit und Sensibilität der Originaldaten nicht beeinträchtigt.
Containerisiertes Image mit Docker erstellen
Anwendungen müssen in einem von Docker erstellten Container-Image verpackt werden, das in Artifact Registry gespeichert ist. Wenn eine Arbeitslast bereitgestellt wird, wird das Docker-Image vom Confidential Space-Image 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:
Zusätzliche Linux-Funktionen
Die Confidential Space-Arbeitslast wird in einem Linux-Container mit containerd ausgeführt. Dieser Container wird mit Standard-Linux-Funktionen ausgeführt.
Um Funktionen hinzuzufügen, können Sie tee-added-capabilities verwenden.
Laufwerks- und Arbeitsspeicherlimits
Confidential Space ändert automatisch die Größe der zustandsbehafteten Partition des Bootlaufwerks, wenn größere Bootlaufwerksgrößen verwendet werden. Die Partitionsgröße entspricht ungefähr der Größe des Bootlaufwerks minus 5 GB.
Im Rahmen der Dateisystemschutzmaßnahmen für die Integrität von Confidential Space werden Datenträger-Integritäts-Tags im Arbeitsspeicher gespeichert. Dies führt zu einem Arbeitsspeicher-Overhead von etwa 1% pro Byte auf der Festplatte. Für eine 100‑GB-Festplatte sind beispielsweise 1 GB Arbeitsspeicher erforderlich, für eine 10‑TB-Festplatte 100 GB.
Achten Sie darauf, die VM-Arbeitsspeicherlimits einzuhalten. Swap-Speicher ist auf Confidential Space-VMs deaktiviert, sodass eine übermäßige Speichernutzung die Arbeitslast abstürzen lassen kann. Achten Sie darauf, dass die von Ihnen ausgewählte Maschine den Arbeitsspeicherbedarf Ihrer Arbeitslast zusätzlich zum Overhead für die Festplattenintegrität unterstützt.
Abgelaufene OIDC-Tokens
Ein OIDC-Token wird für Ihre Arbeitslast zur Verfügung gestellt, wenn sie gestartet wird. Es enthält bestätigte Attestierungsansprüche zur 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 (aufgrund von Netzwerkproblemen, eines Ausfalls des Attestierungsdienstes oder aus anderen Gründen), muss Ihr Workload-Code diesen Fehler beheben können.
Ihre Arbeitslast kann einen Fehler beim Aktualisieren des Tokens auf eine der folgenden Arten behandeln:
Ignorieren Sie das abgelaufene Token, da 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 In-Memory-Scratch-Bereichen. Dabei wird der verfügbare Arbeitsspeicher in der Confidential Space-VM verwendet. Da der Scratch-Bereich den Arbeitsspeicher der Confidential VM verwendet, hat er dieselben Integritäts- und Vertraulichkeitseigenschaften wie die Confidential VM.
Sie können tee-dev-shm-size verwenden, um die Größe der /dev/shm-Freigabe für die Arbeitslast zu erhöhen.
Die Größe von /dev/shm wird in KB angegeben.
Mit tee-mount können Sie tmpfs-Bereitstellungen im laufenden Container mit durch Semikolon getrennten Konfigurationen angeben. type und source sind immer tmpfs. destination ist der Mountpoint, der mit der tee.launch_policy.allow_mount_destinations-Startrichtlinie interagiert. Optional können Sie die tmpfs-Größe 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 ab 230600 verwenden, können Sie beim Erstellen Ihres Arbeitslast-Images in Dockerfile eingehende Ports angeben, die geöffnet bleiben sollen.
Fügen Sie dazu Schlüsselwort EXPOSE mit der Portnummer und einem optionalen Protokoll von tcp oder udp der Dockerfile hinzu, um die Ports zu öffnen. 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 möglicherweise bereits einige Ports freigegeben. Ihr
Dockerfile macht nur zusätzliche Ports verfügbar. Es kann keine Ports blockieren, die bereits vom Basis-Image geöffnet wurden.
Arbeitslastbetreiber sollten 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-Bildinformationen abgerufen werden.
Offengelegte Ports werden in der Konsole protokolliert und an Cloud Logging weitergeleitet, wenn die Metadatavariable tee-container-log-redirect verwendet wird.
Startrichtlinien
Startrichtlinien überschreiben die von Arbeitslastoperatoren festgelegten VM-Metadatavariablen, um schädliche Aktionen einzuschränken. Ein Arbeitslastautor kann beim Erstellen seines Container-Images Richtlinien mit einem Label festlegen.
Beispiel: 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:
| Richtlinie | Typ | Beschreibung |
|---|---|---|
|
Interagiert mit:
|
Boolesch (Standardwert ist false) |
Gibt an, ob der Arbeitslastoperator dem Arbeitslastcontainer zusätzliche Linux-Funktionen hinzufügen kann. |
|
Interagiert mit:
|
Boolesch (Standardwert ist false) |
Bestimmt, ob der Arbeitslastcontainer eine Namespaced-Cgroup-Bereitstellung unter /sys/fs/cgroup enthalten darf.
|
|
Interagiert mit:
|
Boolesch (Standardwert ist false) |
Bestimmt, ob das im Dockerfile des Arbeitslastcontainers angegebene
CMD durch einen Arbeitslastoperator mit dem Metadatenwert
tee-cmd überschrieben werden kann.
|
|
Interagiert mit:
|
Durch Kommas getrennter String |
Ein durch Kommas getrennter String mit zulässigen Umgebungsvariablennamen, die von einem Arbeitslastoperator mit
tee-env-ENVIRONMENT_VARIABLE_NAME-Metadatenwerten festgelegt werden dürfen.
|
|
Interagiert mit:
|
Durch Doppelpunkte getrennter String |
Ein durch Doppelpunkte getrennter String mit zulässigen Bereitstellungsverzeichnissen, in die der Arbeitslastoperator mit Beispiel: |
|
Interagiert mit:
|
Definierter String |
Bestimmt, wie das Logging funktioniert, wenn
Die gültigen Werte sind:
|
|
Interagiert mit:
|
Definierter String |
Bestimmt, wie die Überwachung der Speichernutzung von Arbeitslasten funktioniert, wenn
Die gültigen Werte sind:
|
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 temporären Schlüssel verschlüsselt, um den Angriffsvektor der Änderung eines Arbeitslast-Images auf dem Laufwerk zu beheben, nachdem es heruntergeladen und gemessen wurde.
Außerdem fallen zusätzliche Kosten an, z. B. für die Bootzeit und das Herunterladen des Arbeitslast-Images für jeden Arbeitslastlauf. 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.
Cgroups mit Namespaces
Die Confidential Space-Arbeitslast wird standardmäßig ohne cgroup-Mount ausgeführt.
Wenn Sie Cgroups im Arbeitslastcontainer verwalten möchten, können Sie tee-cgroup-ns verwenden. Dadurch wird im Containerdateisystem eine Bereitstellung unter /sys/fs/cgroup erstellt.
Reproduzierbare Container-Images
Wenn Sie ein Container-Image auf reproduzierbare Weise erstellen, kann dies dazu beitragen, das Vertrauen zwischen den Parteien zu stärken. Sie können reproduzierbare Images mit Bazel erstellen.
Ressourcen, die nicht von Google Cloud IAM verwaltet werden
Wenn Sie auf Ressourcen zugreifen möchten, die nicht von Google Cloud IAM verwaltet werden, muss in Ihrem 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 Datenpartner dann für die Attestierung verwenden kann, anstatt einen Image-Digest in seiner WIP-Richtlinie anzugeben.
Das bedeutet, dass Datenbearbeiter ihre WIP-Richtlinien nicht jedes Mal aktualisieren müssen, wenn eine Arbeitslast aktualisiert wird, und die Arbeitslast weiterhin ohne Unterbrechung auf geschützte Ressourcen zugreifen kann.
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 Metadatavariablen tee-signed-image-repos hinzufügen, bevor sie die Arbeitslast bereitstellen.
Zur Laufzeit werden Signaturen zur Überprüfung an den Attestierungsdienst für Confidential Space gesendet. Der Attestierungsdienst gibt ein Attestierungsanspruchstoken zurück, das die Ansprüche der überprüften Signatur enthält. Hier ein Beispiel für einen Signaturanspruch:
"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 Signierung von Container-Images finden Sie im Codelab für signierte Container-Images.