Arbeitslasten erstellen und anpassen

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 zum Verarbeiten der vertraulichen Daten. Sie können Ihre Anwendung in einer beliebigen Sprache schreiben, sofern Sie ein Container-Image erstellen, das diese Sprache unterstützt.

  • Ein Container-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 sind und steuern, wie eine Arbeitslast ausgeführt werden kann, und die die Möglichkeiten eines böswilligen Arbeitslastoperators einschränken.

Zum Bereitstellen der Arbeitslast wird eine Confidential VM von einem Arbeitslastoperator basierend auf dem Confidential Space-Image ausgeführt. Dadurch wird das Container-Image aus Artifact Registry abgerufen und ausgeführt.

Datenmitarbeiter müssen die Attestierungen einer Arbeitslast validieren, bevor sie auf ihre Daten zugreifen können.

Hinweis

Das Schreiben einer Arbeitslast für Confidential Space umfasst mehr als nur Code und Debugging. Außerdem müssen Sie mit Datenmitarbeitern sprechen, um deren Anforderungen zu bewerten, Ihre Umgebung einzurichten, Ihren Code in ein Container-Image zu packen und mit einem Workload-Operator zusammenzuarbeiten, um sicherzustellen, dass alles korrekt bereitgestellt wird.

Mit den Datenmitarbeitenden sprechen

Bevor Sie mit dem Schreiben Ihrer Anwendung beginnen, müssen Sie sich mit Ihren Datenpartnern über die privaten Daten unterhalten, mit denen Sie arbeiten sollen. Folgende Fragen können Sie stellen:

  • Welche Organisations-IDs sind betroffen?

  • Wie lauten die betroffenen Projektnummern?

  • 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?

  • 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 Datenmitarbeiter dasselbe Ergebnis oder sind die Ausgaben für jeden einzigartig?

Außerdem hat jeder Datenmitbearbeiter 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 entsprechenden Berechtigungen als Testumgebung einzurichten, wie unter Erste Confidential Space-Umgebung erstellen beschrieben. Versuchen Sie, die Projekteinstellungen der Daten-Mitbearbeiter so gut wie möglich zu spiegeln. 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 „Workload Operator“ und „Data Collaborator“ und ihren Verantwortlichkeiten machen.

In der frühen Entwicklungsphase ist es sinnvoll, die folgenden Best Practices zu beachten:

  • Wenn Sie als Datenbearbeiter arbeiten, sollten Sie die Attestierungsvalidierung auf ein Minimum beschränken, um die Entwicklungsgeschwindigkeit zu erhöhen.

  • Wenn Sie als Arbeitslastoperator arbeiten, verwenden Sie beim Bereitstellen der Arbeitslast das Confidential Space-Debugging-Image anstelle des Produktions-Images. So haben Sie mehr Möglichkeiten, Fehler in der Arbeitslast zu beheben.

Wenn Ihre Anwendung ausgereift ist und ihr Status vorhersehbarer wird, können Sie Ihre Lösung zunehmend mit Attestierungsvalidierung und Startrichtlinien sperren und zum Confidential Space-Produktions-Image wechseln.

Nachdem Ihre Arbeitslast in Ihrer Testumgebung korrekt funktioniert, können Sie zum Testen in den Projekten Ihrer Datenpartner mit echten Ressourcen, aber gefälschten Daten wechseln, um den Datenpartnern zu zeigen, wie alles funktioniert. Zu diesem Zeitpunkt arbeiten Sie möglicherweise mit einem unabhängigen Arbeitslastoperator.

Wenn alles funktioniert und die Ausgabe wie erwartet ist, können Sie mit dem Testen von Produktionsdaten beginnen. Nachdem diese Tests abgeschlossen sind und alle Parteien die Ergebnisse genehmigt haben, kann die Arbeitslast in die Produktion überführt werden.

Vorsicht bei der Ausgabe

Beim Testen Ihres Codes kann es verlockend sein, Fehler durch Ausgabe in STDOUT oder STDERR zu beheben. Wenn Sie dies tun, 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 eingesetzt wird, sollten Sie darauf achten, dass er nur das ausgibt, was unbedingt erforderlich ist.

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 gefährdet.

Container-Image mit Docker erstellen

Anwendungen müssen in einem von Docker erstellten Container-Image verpackt werden, das 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 der Arbeit an den entsprechenden Projektressourcen beginnen.

Berücksichtigen 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 den standardmäßigen Linux-Funktionen ausgeführt.

Wenn Sie Funktionen hinzufügen möchten, können Sie tee-added-capabilities verwenden.

Laufwerks- und Speicherlimits

Confidential Space passt die Größe der zustandsorientierten Partition des Bootlaufwerks automatisch an, wenn größere Bootlaufwerke verwendet werden. Die Partitionsgröße entspricht ungefähr der Größe des Bootlaufwerks minus 5 GB.

Im Rahmen der Integritätsschutzmaßnahmen für das Dateisystem von Confidential Space werden Laufwerksintegritäts-Tags im Arbeitsspeicher gespeichert. Dabei wird pro Laufwerk-Byte etwa 1 % Arbeitsspeicher-Overhead verwendet. Beispielsweise benötigt ein Laufwerk mit 100 GB 1 GB Arbeitsspeicher und ein Laufwerk mit 10 TB 100 GB Arbeitsspeicher.

Achten Sie darauf, die Arbeitsspeicherlimits der VM nicht zu überschreiten. Swap-Speicher ist auf Confidential Space-VMs deaktiviert, sodass eine übermäßige Speichernutzung die Arbeitslast abstürzen lassen kann. Prüfen Sie, ob die ausgewählte Maschine die Arbeitsspeichernutzung Ihrer Arbeitslast zusätzlich zum Overhead für die Laufwerksintegrität unterstützt.

Ordnungsgemäßes Herunterfahren

Wenn ein Operator das Herunterfahren einer Confidential Space-VM anfordert, versucht der Confidential Space Launcher, die Arbeitslast ordnungsgemäß herunterzufahren, indem er ein SIGTERM-Signal sendet. Nach dem Empfang hat die Arbeitslast bis zu 120 Sekunden Zeit, um die Bereinigung durchzuführen, bevor der Confidential Space Launcher den Herunterfahrvorgang startet. Arbeitslasten, die keine SIGTERM-Signalverarbeitung implementieren, werden sofort nach Erhalt des Signals beendet.

In-Memory-Scratch-Bereitstellungen

Confidential Space unterstützt das Hinzufügen von Scratch-Speicher im Arbeitsspeicher. Dabei wird der verfügbare Arbeitsspeicher in der Confidential Space-VM verwendet. Da der Scratch-Speicher 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 freigegebenen Speicherbereitstellung /dev/shm 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 laufenden Container mit durch Semikolons getrennten Konfigurationen angeben. type und source sind immer tmpfs. destination ist der Bereitstellungspunkt, der mit der Startrichtlinie tee.launch_policy.allow_mount_destinations 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 ausgeführt, die alle eingehenden Ports blockiert. Wenn Sie Confidential Space-Image-Version 230600 oder höher verwenden, können Sie eingehende Ports beim Erstellen Ihres Arbeitslast-Images in Dockerfile angeben.

Fügen Sie dazu 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. Ports, die bereits vom Basis-Image geöffnet wurden, können nicht blockiert werden.

Arbeitslastoperatoren sollten vor dem Ausführen der Arbeitslast prüfen, ob die freigegebenen Ports in ihrer VPC-Firewall geöffnet sind. Die Portnummern können vom Ersteller der Arbeitslast angegeben oder aus den Docker-Image-Informationen abgerufen werden.

Verfügbare Ports werden in der Console protokolliert und bei Verwendung der Metadatenvariable tee-container-log-redirect an Cloud Logging weitergeleitet.

Startrichtlinien

Startrichtlinien überschreiben die VM-Metadatenvariablen, die von Arbeitslastoperatoren festgelegt wurden, um schädliche Aktionen einzuschränken. Ein Arbeitslastautor kann beim Erstellen des Container-Images Richtlinien mit einem Label festlegen.

Beispielwesie 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

tee.launch_policy.allow_capabilities

Interagiert mit:

 Boolesch (Standardwert ist false) Bestimmt, ob der Arbeitslastoperator dem Arbeitslastcontainer zusätzliche Linux-Funktionen hinzufügen kann.

tee.launch_policy.allow_cgroups

Interagiert mit:

 Boolesch (Standardwert ist false) Bestimmt, ob der Arbeitslastcontainer eine cgroup-Bereitstellung mit Namespace unter /sys/fs/cgroup enthalten darf.

tee.launch_policy.allow_cmd_override

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.

tee.launch_policy.allow_env_override

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.

tee.launch_policy.allow_mount_destinations

Interagiert mit:

  • Arbeitslastoperator: Die Metadatenvariable tee-mount.
 Durch Doppelpunkte getrennter String

Ein durch Doppelpunkte getrennter String mit zulässigen Bereitstellungsverzeichnissen, die der Arbeitslastoperator mit tee-mount bereitstellen darf.

Beispiel: /run/tmp:/var/tmp:/tmp

tee.launch_policy.log_redirect

Interagiert mit:

 Definierter String

Bestimmt, wie das Logging funktioniert, wenn tee-container-log-redirect von einem Arbeitslastoperator auf true gesetzt wird.

Folgende Werte sind gültig:

  • debugonly (Standard): Nur stdout- und stderr-Weiterleitungen zulassen, wenn ein Debug-Image verwendet wird.
  • always: Lässt immer stdout- und stderr-Weiterleitungen zu.
  • never: Lässt niemals stdout- und stderr-Weiterleitungen zu.

tee.launch_policy.monitoring_memory_allow

Interagiert mit:

 Definierter String

Bestimmt, wie das Monitoring der Arbeitsspeichernutzung von Arbeitslasten funktioniert, wenn tee-monitoring-memory-enable von einem Arbeitslastoperator auf true gesetzt wird.

Folgende Werte sind gültig:

  • debugonly (Standard): Monitoring der Arbeitsspeichernutzung nur bei Verwendung eines Debug-Images zulassen.
  • always: Monitoring der Arbeitsspeichernutzung immer zulassen.
  • never: Monitoring der Arbeitsspeichernutzung nie zulassen.

tee.launch_policy.nonroot_container

Interagiert mit:

 Definierter String

Bestimmt, ob die Ausführungsberechtigungen des Containers eingeschränkt werden sollen.

Folgende Werte sind gültig:

  • unrestricted (Standard): Der Arbeitslastautor lässt zu, dass der Container als Root oder Nicht-Root ausgeführt wird. Der Arbeitslastoperator wählt mit tee-nonroot-container aus.
  • nonrootonly: Der Ersteller der Arbeitslast verlangt, dass der Container als Nutzer ohne Root-Berechtigung ausgeführt wird. Der Arbeitslastoperator muss tee-nonroot-container auf true festlegen, da die VM die Arbeitslast sonst nicht starten kann.

Mehrere Arbeitslastausführungen

Wenn eine Arbeitslast noch einmal ausgeführt werden soll, muss der Arbeitslastoperator die VM-Instanz neu starten. Dadurch wird die Arbeitslast in einer möglichst sauberen Umgebung gestartet und das Laufwerk der VM-Instanz mit einem neuen sitzungsspezifischen Schlüssel verschlüsselt.

Durch den Neustart wird der Angriffsvektor behoben, bei dem ein Arbeitslast-Image auf dem Laufwerk geändert wird, nachdem es heruntergeladen und gemessen wurde. Allerdings entstehen dadurch auch zusätzliche Kosten, z. B. für 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.

Namespaced-cgroups

Die Confidential Space-Arbeitslast wird standardmäßig ohne cgroup-Bereitstellung ausgeführt.

Zum Verwalten von cgroups im Arbeitslastcontainer können Sie tee-cgroup-ns verwenden. Dieser Metadatenschlüssel weist die VM-Instanz an, eine Bereitstellung unter /sys/fs/cgroup im Containerdateisystem zu erstellen.

Ausführung von Nicht-Root-Containern

Sie können einen Container optional als Nutzer ohne Root-Berechtigung ausführen, um die Auswirkungen eines Container-Breakouts zu reduzieren. Wenn die Ausführung von Containern ohne Root-Berechtigung aktiviert ist, konfiguriert Confidential Space einen Linux-Nutzer-Namespace und einen Netzwerk-Namespace für die Arbeitslast. Die Container-UIDs und -GIDs 0–65535 werden auf der Confidential VM nicht privilegierten IDs ab 100000 zugeordnet. Ein Prozess, der im Container als Root ausgeführt wird oder ihn verlässt, hat nur nicht privilegierten Zugriff auf die VM. Sie müssen Ihrer Dockerfile keine USER-Anweisung hinzufügen.

Für die Ausführung ohne Root-Berechtigung ist das Confidential Space-Image confidential-space-261001 oder höher erforderlich. Sie können es als optional oder erforderlich konfigurieren:

  • Arbeitslastautor: Verwenden Sie das Startrichtlinienlabel tee.launch_policy.nonroot_container in Ihrem Container-Image. Wenn diese Richtlinie auf nonrootonly gesetzt ist, muss der Arbeitslastoperator den Container als Nicht-Root-Nutzer ausführen.

  • Arbeitslastoperator: Übergeben Sie beim Erstellen der VM die Metadatenvariable tee-nonroot-container=true. Wenn der Ersteller der Arbeitslast nonrootonly festlegt, ist diese Metadatenvariable erforderlich. Andernfalls kann die VM die Arbeitslast nicht starten.

Reproduzierbare Container-Images

Wenn Sie ein Container-Image reproduzierbar erstellen, kann dies das Vertrauen zwischen den Parteien stärken. Sie können reproduzierbare Images mit Bazel erstellen.

Nicht von Google Cloud IAM verwaltete Ressourcen

Für den Zugriff auf Ressourcen, 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 Datenmitarbeiter 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. 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 Arbeitslastoperatoren die Signaturinformationen vor der Bereitstellung der Arbeitslast der Metadatenvariable tee-signed-image-repos hinzufügen.

Während der Laufzeit werden Signaturen zur Überprüfung an einen Attestierungsdienst gesendet. Der Attestierungsdienst gibt ein Attestierungsanspruchstoken zurück, das die verifizierten Signaturansprüche 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 zu signierten Container-Images.