Eine Arbeitslast wird von einem Arbeitslastautor erstellt und verarbeitet die vertraulichen Daten, mit denen Datenmitarbeiter arbeiten möchten.
Ein Arbeitslastautor muss die folgenden Ressourcen zusammenstellen, um eine Arbeitslast zu erstellen:
Eine Anwendung zum Verarbeiten der vertraulichen Daten. Sie können Ihre Anwendung in einer beliebigen Sprache schreiben, sofern Sie ein containerisiertes Image erstellen, das die 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
Eine Arbeitslast für Confidential Space zu schreiben, ist mehr als nur Code und Debugging. Außerdem müssen Sie mit Datenmitarbeitern sprechen, um ihre Anforderungen zu ermitteln, Ihre Umgebung einzurichten, Ihren Code in einem Container-Image zu verpacken und mit einem Workload-Operator zusammenzuarbeiten, 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 Beispiele für Fragen, die Sie stellen können:
Welche Organisations-IDs sind betroffen?
Welche Projektnummern sind betroffen?
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 von Google CloudIAM verwaltet werden?
Wie sollte die Anwendung die privaten Daten vergleichen und verarbeiten?
In welchem Format soll die Ausgabe erfolgen?
Wo soll die Ausgabe gespeichert werden und soll sie verschlüsselt werden?
Sehen alle Mitbearbeiter dieselben Ergebnisse 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 Projekteinrichtungen 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 zur Fehlerbehebung bei der Arbeitslast.
Wenn Ihre Anwendung ausgereifter ist und ihr Status besser vorhersehbar 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 dann zu Tests in den Projekten Ihrer Datenpartner mit echten Ressourcen, aber gefälschten Daten wechseln, 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 Ihres Codes kann es verlockend sein, Fehler zu beheben, indem Sie in STDOUT oder STDERR ausgeben. Achten Sie dabei darauf, dass Sie keine privaten Daten preisgeben, die andere durch den 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 Ausgaben erzeugt.
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, ausgeführt und die Anwendung kann 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 Bootlaufwerke 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 ein 100‑GB-Laufwerk ist beispielsweise 1 GB Arbeitsspeicher erforderlich, für ein 10‑TB-Laufwerk 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 neben dem Overhead für die Festplattenintegrität auch die Arbeitsspeichernutzung Ihrer Arbeitslast unterstützt.
Abgelaufene OIDC-Tokens
Ein OIDC-Token wird für Ihre Arbeitslast bereitgestellt, 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-Arbeitsbereichen. Dabei wird der verfügbare Arbeitsspeicher in 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.
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 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 eingehende Ports angeben, die in Dockerfile 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 den Port 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-Image-Informationen 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: 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:
| 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) |
Gibt an, 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
von einem Arbeitslastoperator mit dem Metadatenwert
tee-cmd
überschrieben werden kann.
|
|
Interagiert mit:
|
Durch Kommas getrennter String |
Eine durch Kommas getrennte Liste der 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, 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 entstehen zusätzliche Kosten, z. B. für die Startzeit 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.
Namespaced-Cgroups
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 Dateisystem des Containers 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 vor der Bereitstellung der Arbeitslast der Metavariable tee-signed-image-repos hinzufügen.
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.