Eine Arbeitslast wird von einem Arbeitslastautor erstellt und verarbeitet die vertraulichen Daten, mit denen Datenbearbeiter 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 containerisiertes Image, in das die Anwendung mit Docker verpackt wird.
Ein Repository in Artifact Registry, in dem das Docker- Image gespeichert wird.
Startrichtlinien , die für das Container-Image festgelegt wurden und steuern, wie eine Arbeitslast ausgeführt werden kann. Außerdem schränken sie die Möglichkeiten eines böswilligen Arbeitslastoperators ein.
Zum Bereitstellen der Arbeitslast wird eine Confidential VM von einem Arbeitslastoperator auf Grundlage des Confidential Space-Images ausgeführt. Dabei 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 kann.
Hinweis
Das Schreiben einer Arbeitslast für Confidential Space ist mehr als nur Code und Debugging. Sie müssen auch mit Datenbearbeitern sprechen, um ihre Anforderungen zu ermitteln, Ihre Umgebung einzurichten, Ihren Code in ein containerisiertes Image zu verpacken und mit einem Arbeitslastoperator zusammenzuarbeiten, um sicherzustellen, dass alles korrekt bereitgestellt wird.
Mit den Datenbearbeitern sprechen
Bevor Sie mit dem Schreiben Ihrer Anwendung beginnen, müssen Sie mit Ihren Datenbearbeitern über die privaten Daten sprechen, die Sie verarbeiten sollen. Sie können unter anderem folgende Fragen stellen:
Welche Organisations-IDs sind beteiligt?
Welche Projektnummern sind beteiligt?
Auf welche Ressourcen muss ich zugreifen und wie lauten ihre IDs und Namen? Google Cloud
Gibt es Ressourcen, auf die ich zugreifen muss, die nicht von Google Cloud IAM verwaltet werden?
Welchen Attestierungsdienst möchten Sie verwenden: Google Cloud Attestation oder Intel Trust Authority?
Wie soll 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 Datenbearbeiter dasselbe Ergebnis oder sind die Ausgaben für jeden eindeutig?
Außerdem hat jeder Datenbearbeiter möglicherweise eigene Datenschutzanforderungen, die Sie erfüllen müssen. Es ist von entscheidender Bedeutung, dass durch eine 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 unter Erste Confidential Space-Umgebung erstellen beschrieben. Versuchen Sie, die Projekteinrichtungen der Datenbearbeiter so gut wie möglich nachzubilden. So können Sie Erfahrungen mit projektübergreifenden Berechtigungen sammeln und die benötigten Daten, die Sie aus bestimmten Google Cloud Ressourcen benötigen, abrufen. Außerdem können Sie sich ein Bild von den Rollen des Arbeitslastoperators und des Datenbearbeiters und ihren Verantwortlichkeiten machen.
In der frühen Entwicklungsphase ist es hilfreich, die folgenden Best Practices zu beachten:
Wenn Sie als Datenbearbeiter arbeiten, sollten Sie die Attestierungsvalidierung aus Gründen der Entwicklungsgeschwindigkeit auf ein Minimum beschränken.
Wenn Sie als Arbeitslastoperator arbeiten, verwenden Sie beim Bereitstellen der Arbeitslastdas 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 Zustand besser vorhersehbar wird, können Sie Ihre Lösung zunehmend mit Attestierungsvalidierung und Startrichtliniensichern 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 Datenbearbeiter mit echten Ressourcen, aber gefälschten Daten fortfahren, damit Sie den Datenbearbeitern zeigen können, wie alles funktioniert. An diesem Punkt 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 die Arbeitslast in die Produktion überführt werden.
Vorsicht bei der Ausgabe
Beim Testen Ihres Codes kann es verlockend sein, Fehler zu beheben, indem Sie in STDOUT oder STDERR ausgeben. Wenn Sie dies tun, achten Sie darauf, dass Sie keine privaten Daten offenlegen, die andere Parteien durch den Zugriff auf Logs lesen könnten. Bevor Ihr Code in der Produktion verwendet wird, prüfen Sie, ob er nur das ausgibt, was unbedingt erforderlich ist.
Das Gleiche gilt für die endgültige Ausgabe. Geben Sie nur ein Endergebnis an, das die Privatsphäre und Vertraulichkeit der ursprünglichen Daten nicht beeinträchtigt.
Containerisiertes Image mit Docker erstellen
Anwendungen müssen in ein containerisiertes Image verpackt werden, das von Docker erstellt und in Artifact Registry gespeichert wird. 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.
Berücksichtigen Sie beim Erstellen Ihres Docker-Images Folgendes:
Ressourcen, die nicht von Google Cloud IAM verwaltet werden
Zusätzliche Linux-Funktionen
Die Confidential Space-Arbeitslast wird in einem Linux-Container mit containerd ausgeführt. Dieser Container wird mit den Standard-Linux-Funktionen ausgeführt.
Mit
tee-added-capabilities können Sie Funktionen hinzufügen.
Laufwerk- und Arbeitsspeicherlimits
Confidential Space ändert die Größe der zustandsorientierten Partition des Bootlaufwerks automatisch, 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 speichert Confidential Space Tags zur Laufwerkintegrität im Arbeitsspeicher. Dabei wird für jedes Byte auf dem Laufwerk ein Arbeitsspeicher-Overhead von etwa 1% verwendet. Ein 100-GB-Laufwerk benötigt beispielsweise 1 GB Arbeitsspeicher und ein 10-TB-Laufwerk 100 GB Arbeitsspeicher.
Achten Sie darauf, die Arbeitsspeicherlimits für VMs einzuhalten. Swap-Speicher ist auf Confidential Space-VMs deaktiviert, sodass eine übermäßige Speichernutzung die Arbeitslast abstürzen lassen kann. Prüfen Sie, ob Ihre Maschinenauswahl neben dem Overhead für die Laufwerkintegrität auch die Arbeitsspeichernutzung Ihrer Arbeitslast unterstützt.
Speicherinterne Scratch-Bereitstellungen
Confidential Space unterstützt das Hinzufügen von speicherinternen 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.
Mit
tee-dev-shm-size
können Sie die Größe der /dev/shmBereitstellung des gemeinsam genutzten Arbeitsspeichers für die Arbeitslast erhöhen.
Die Größe von /dev/shm wird in KB angegeben.
Mit
tee-mount können Sie
tmpfs-Bereitstellungen im ausgeführten Container mit durch Semikolons getrennten Konfigurationen angeben.
type und source sind immer tmpfs. The 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 verwenden Confidential Space-VMs eine Firewallregel, um alle eingehenden Ports zu blockieren. Wenn Sie Confidential Space-Image-Version 230600 oder höher verwenden, können Sie eingehende Ports beim Erstellen Ihres Arbeitslast-Images in der Dockerfile angeben.
Fügen Sie das Schlüsselwort EXPOSE zusammen mit der Portnummer, die offen bleiben soll, und einem optionalen Protokoll (tcp oder udp) zu Ihrer Dockerfile hinzu, um 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 eine Dockerfile, mit der 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 offengelegt. Ihre Dockerfile legt nur zusätzliche Ports offen. Sie kann keine Ports blockieren, die bereits vom Basis-Image geöffnet wurden.
Arbeitslastoperatoren sollten prüfen, ob die offengelegten Ports in ihrer VPC-Firewall geöffnet sind, bevor sie die Arbeitslast ausführen. Die Portnummern können vom Arbeitslastautor angegeben oder aus den Docker-Image-Informationen abgerufen werden.
Offengelegte Ports werden in der Konsole protokolliert und zu Cloud Logging weitergeleitet
wenn die
tee-container-log-redirect
Metadatenvariable verwendet wird.
Startrichtlinien
Startrichtlinien überschreiben die VM-Metadatenvariablen , die von Arbeitslastoperatoren festgelegt wurden, um böswillige Aktionen einzuschränken. Ein Arbeitslastautor kann beim Erstellen seines Container-Images Richtlinien mit einem Label festlegen.
Beispiel in einer 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) |
Bestimmt, ob der Arbeitslastoperator dem Arbeitslastcontainer zusätzliche Linux-Funktionen hinzufügen kann. |
|
Interagiert mit :
|
Boolesch (Standardwert ist false) |
Bestimmt, ob der Arbeitslastcontainer eine Bereitstellung von Cgroups mit Namespace unter /sys/fs/cgroup enthalten darf.
|
|
Interagiert mit :
|
Boolesch (Standardwert ist false) |
Bestimmt, ob der
CMD
in der Dockerfile des Arbeitslastcontainers angegebene
überschrieben werden kann von einem Arbeitslastoperator mit dem
tee-cmd
Metadatenwert.
|
|
Interagiert mit :
|
Kommagetrennter String |
Ein kommagetrennter 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, die der Arbeitslast
operator 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 Arbeitsspeichernutzung der Arbeitslast funktioniert, wenn
Die gültigen Werte sind:
|
Mehrere Arbeitslastausführungen
Um eine Arbeitslast noch einmal auszuführen, muss der Arbeitslastoperator die VM-Instanz neu starten. Dadurch wird die Arbeitslast in der saubersten möglichen Umgebung gestartet und das Laufwerk der VM-Instanz mit einem neuen kurzlebigen Schlüssel verschlüsselt.
Durch den Neustart wird der Angriffsvektor der Änderung eines Arbeitslast-Images auf dem Laufwerk nach dem Herunterladen und Messen beseitigt. Allerdings entstehen dadurch auch zusätzliche Kosten wie die Startzeit und das Abrufen des Arbeitslast-Images bei jeder Arbeitslastausführung. Wenn diese Kosten die Leistung Ihrer Arbeitslast zu stark beeinträchtigen, können Sie auf Kosten eines erhöhten Risikoprofils einen Neustart der Arbeitslast in die Arbeitslast selbst codieren.
Namespace-Cgroups
Die Confidential Space-Arbeitslast wird standardmäßig ohne eine Cgroup-Bereitstellung ausgeführt.
Mit
tee-cgroup-ns können Sie Cgroups im Arbeitslastcontainer verwalten. Dieser Metadatenschlüssel weist die VM-Instanz an, eine Bereitstellung unter /sys/fs/cgroup im Containerdateisystem zu erstellen.
Reproduzierbare Container-Images
Das Erstellen eines Container-Images auf reproduzierbare Weise kann 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 Ihre Arbeitslast auf Ressourcen zugreifen muss, die nicht von Google Cloud IAM verwaltet werden, muss Ihre Arbeitslast eine benutzerdefinierte Zielgruppe angeben.
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 einen Image-Digest in seiner WIP-Richtlinie anzugeben.
So müssen Datenbearbeiter ihre WIP-Richtlinien nicht jedes Mal aktualisieren, wenn eine Arbeitslast aktualisiert wird, und die Arbeitslast kann weiterhin ohne Unterbrechung 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 Arbeitslast
operatoren die Signaturinformationen der
tee-signed-image-repos
Metadatenvariablen hinzufügen, bevor sie die Arbeitslast bereitstellen.
Während der Laufzeit werden Signaturen zur Überprüfung an einen Attestierungsdienst gesendet. Der Attestierungsdienst gibt ein Attestierungs-Claim-Token zurück, das die verifizierten Signatur-Claims enthält. Hier ist ein Beispiel für einen Signatur-Claim:
"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.