Attestierungs-Assertions

Weitere Informationen zur Verwendung von Attestierungs-Assertions finden Sie unter Attestierungsrichtlinie erstellen.

Die verfügbaren Assertions zum Erstellen einer Attestierungsrichtlinie sind in der folgenden Tabelle aufgeführt. Mit Richtlinien können Assertions validiert werden, die vom Confidential Space-Image, vom Arbeitslastcontainer und von der VM-Instanz erstellt wurden.

Image-Assertions

Assertion Typ Beschreibung

assertion.dbgstat

Interagiert mit:

 Aufzählung

Prüft, ob das Confidential Space-Image die Debugging- oder Produktionsversion ist.

Folgende Werte sind gültig:

  • enable: Prüfen Sie, ob das Debug-Image verwendet wird.
  • disabled-since-boot: Prüfen, ob das Produktions-Image verwendet wird.
Beispiele

Mit dem folgenden Code wird geprüft, ob die Debugging-Version des Confidential Space-Images verwendet wird: 

assertion.dbgstat == "enable"

Mit dem folgenden Code wird geprüft, ob die Produktionsversion des Confidential Space-Images verwendet wird: 

assertion.dbgstat == "disabled-since-boot"
assertion.submods.confidential_space.support_attributes Stringarray

Prüft, ob die Sicherheitsversion des TEE ein Confidential Space-Produktions-Image ist. Für Confidential Space-Debug-Images ist kein Support-Attribut festgelegt.

In der folgenden Tabelle werden die Support-Attribute für Confidential Space-Produktions-Images beschrieben.

Support-Attribut Beschreibung

LATEST

LATEST-Images haben außerdem die folgenden Support-Attribute:

  • STABLE
  • USABLE

Lebensdauer des Bildes: Ungefähr ein Monat. Danach wird das Support-Attribut LATEST entfernt.

Dies ist die neueste Version des Confidential Space-Images. Sie wird unterstützt und auf Sicherheitslücken überwacht.

Für Arbeitslasten mit langer Ausführungszeit empfehlen wir, LATEST nicht als Teil Ihrer Attestierungsrichtlinie anzugeben. Das liegt daran, dass das Confidential Space-Image möglicherweise aktualisiert wird, während Ihre Arbeitslast ausgeführt wird. Dadurch ist das von Ihnen verwendete Confidential Space-Image nicht mehr LATEST und Ihre Arbeitslast schlägt bei der Attestierung fehl, wenn das Confidential Space-Standardtoken das nächste Mal aktualisiert wird.

STABLE

STABLE-Images haben außerdem die folgenden Support-Attribute:

  • USABLE

Lebensdauer des Images: Ungefähr sechs Monate. Ab dem 1. April 2027 wird das Support-Attribut STABLE nach Ablauf der Image-Lebensdauer entfernt.

Images mit dem Attribut STABLE werden sechs Monate lang unterstützt und auf Sicherheitslücken überwacht. Wir empfehlen, die Attestierungsrichtlinie auf Grundlage des Attributs STABLE zu schreiben.

In seltenen Fällen kann das Attribut STABLE während des normalen sechsmonatigen Supportzeitraums entfernt werden, z. B. wenn kritische Sicherheitslücken entdeckt werden.

USABLE

Images, die nur das Attribut USABLE haben, können weiterhin verwendet werden, gelten aber als veraltet. Verworfene Images werden nicht unterstützt und sind älter als sechs Monate. Die Nutzung erfolgt auf eigenes Risiko.

USABLE-Images haben das Attribut deprecated.deprecated. Der Wert ist der Zeitstempel, zu dem das Image voraussichtlich verworfen wird. Die Attribute eines Images können mit dem Befehl gcloud compute images describe oder der REST-Methode images.get angezeigt werden. Beispiel: 

gcloud compute images describe confidential-space-240800 \
    --format=json \
    --project=confidential-space-images
EXPERIMENTAL

Images, die nur dieses Attribut haben, verwenden Funktionen in der Vorabversion. EXPERIMENTAL-Images sind nur für Testzwecke gedacht und sollten niemals in der Produktion verwendet werden.

Ein EXPERIMENTAL-Image hat nie die Attribute LATEST, STABLE oder USABLE.

Wir empfehlen, Ihr Confidential Space-Image auf dem neuesten Stand zu halten. Informationen zum Aktualisieren Ihres Confidential Space-Images finden Sie unter Confidential Space-Images aktualisieren.

Beispiel

Mit dem folgenden Code wird geprüft, ob eine stabile Version des Confidential Space-Images verwendet wird: 

"STABLE" in assertion.submods.confidential_space.support_attributes
assertion.swname Aufzählung

Verifiziert die Software, die auf der attestierenden Entität ausgeführt wird. Der Wert ist immer CONFIDENTIAL_SPACE.

Beispiel
assertion.swname == "CONFIDENTIAL_SPACE"
assertion.swversion Stringarray

Verifiziert die Softwareversion des Confidential Space-Images. Wir empfehlen, stattdessen assertion.submods.confidential_space.support_attributes zu verwenden, um die aktuelle Version eines Images anzusprechen.

Beispiel
int(assertion.swversion[0]) == 230103

Container-Assertions

Assertion Typ Beschreibung

assertion.submods.container.cmd_override

Interagiert mit:

 Stringarray

Verifiziert die CMD-Befehle und -Parameter, die im Arbeitslast-Image verwendet werden.

Beispiele

Mit dem folgenden Code wird geprüft, ob der CMD des Arbeitslast-Images nicht überschrieben wurde: 

size(assertion.submods.container.cmd_override) == 0

Mit dem folgenden Code wird geprüft, ob program der einzige Inhalt in den CMD-Überschreibungen ist: 

assertion.submods.container.cmd_override == ['program']

assertion.submods.container.env

Interagiert mit:

 JSON-Objekt

Verifiziert, dass Umgebungsvariablen und deren Werte explizit an den Container übergeben wurden.

Beispiel

Mit dem folgenden Code wird geprüft, ob die Umgebungsvariable example-env-1 auf value-1 und example-env-2 auf value-2 gesetzt ist. 

assertion.submods.container.env == {"example-env-1": "value-1", "example-env-2": "value-2"}

assertion.submods.container.env_override

Interagiert mit:

 String

Prüft, ob der Arbeitslastoperator Umgebungsvariablen im Container überschrieben hat.

Beispiele

Mit dem folgenden Code wird geprüft, ob der Arbeitslastoperator die Umgebungsvariable example überschrieben hat: 

!has(assertion.submods.container.env_override.example)

Mit dem folgenden Code wird geprüft, ob der Arbeitslastoperator Umgebungsvariablen überschrieben hat: 

size(assertion.submods.container.env_override) == 0
assertion.submods.container.image_digest String

Verifiziert den Image-Digest des Arbeitslastcontainers. Durch die Angabe dieser Bedingung können mehrere Parteien einer autorisierten Arbeitslast zustimmen, die auf ihre Daten zugreifen darf.

Beispiel
assertion.submods.container.image_digest == "sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b"
assertion.submods.container.image_id String

Verifiziert die Image-ID des Arbeitslastcontainers.

Beispiel
assertion.submods.container.image_id == "sha256:652a44b0e911271ba07cf2915cd700fdfa50abd62a98f87a57fdebc59843d93f"

assertion.submods.container.image_reference

Interagiert mit:

 String

Verifiziert den Speicherort des Arbeitslastcontainers, der auf dem Confidential Space-Image ausgeführt wird.

Beispiel
assertion.submods.container.image_reference == "us-docker.pkg.dev/PROJECT_ID/WORKLOAD_CONTAINER:latest"

assertion.submods.container.image_signatures

Interagiert mit:

 JSON-Objekt

Prüft, ob das Image eine bestimmte Signatur hat oder mit einem öffentlichen Schlüssel und einem Signaturalgorithmus signiert ist. Durch die Angabe dieser Bedingung können mehrere Parteien einer autorisierten Arbeitslast zustimmen, die auf ihre Daten zugreifen darf.

Die Assertion kann die folgenden Elemente enthalten:

  • key_id: Der hexadezimale Fingerabdruck des öffentlichen Schlüssels. Führen Sie den folgenden Befehl aus, um den Fingerabdruck abzurufen: 

    openssl pkey -pubin -in public_key.pem -outform DER | openssl sha256

    Dabei ist public_key.pem Ihr öffentlicher Schlüssel im PEM-Format.

  • signature: Die Signatur über eine Nutzlast, die mit dem signierten Container verknüpft ist und dem einfachen Signaturformat folgt.

  • signature_algorithm: Der zum Signieren des Schlüssels verwendete Algorithmus. Eines der folgenden Betriebssysteme:

    • RSASSA_PSS_SHA256 (RSASSA-PSS mit einem SHA-256-Digest)
    • RSASSA_PKCS1V15_SHA256 (RSASSA-PKCS1 v1_5 mit einem SHA-256-Digest)
    • ECDSA_P256_SHA256 (ECDSA auf der P-256-Kurve mit einem SHA-256-Digest)
Beispiel
['ECDSA_P256_SHA256:PUBLIC_KEY_FINGERPRINT'].exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig, sig.signature_algorithm+':'+sig.key_id))

assertion.submods.container.restart_policy

Interagiert mit:

 Aufzählung

Prüft die Neustart-Richtlinie des Container-Launchers, wenn die Arbeitslast beendet wird.

Folgende Werte sind gültig:

  • Never (Standard)
  • Always
  • OnFailure
Beispiel
assertion.submods.container.restart_policy == "Never"

VM-Assertions

Assertion Typ Beschreibung

assertion.google_service_accounts

Interagiert mit:

 Stringarray

Prüft, ob ein bestimmtes Dienstkonto mit der VM verbunden ist, auf der die Arbeitslast ausgeführt wird, oder mit tee-impersonate-service-accounts in den VM-Metadaten aufgelistet wurde.

Beispiel
workload-service-account@my-project. in assertion.google_service_accounts
assertion.hwmodel String

Verifiziert die zugrunde liegende Confidential Computing-Technologie. Die unterstützten Plattformen sind:

  • GCP_AMD_SEV
  • INTEL_TDX
Beispiel
assertion.hwmodel == "GCP_AMD_SEV"

assertion.submods.confidential_space.monitoring_enabled

Interagiert mit:

 Boolesch

Prüft den Monitoringstatus auf der attestierenden Entität.

Beispiel
assertion.submods.confidential_space.monitoring_enabled.memory == true
assertion.submods.gce.instance_id String

Verifiziert die VM-Instanz-ID.

Beispiel
assertion.submods.gce.instance_id == "0000000000000000000"
assertion.submods.gce.instance_name String

Verifiziert den Namen der VM-Instanz.

Beispiel
assertion.submods.gce.instance_name == "workload-vm"
assertion.submods.gce.project_id String

Prüft, ob auf der VM ein Google Cloud -Projekt mit der angegebenen Projekt-ID ausgeführt wird.

Beispiel
assertion.submods.gce.project_id == "project-id"
assertion.submods.gce.project_number String

Prüft, ob die VM in einem Google Cloud -Projekt mit der angegebenen Projektnummer ausgeführt wird.

Beispiel
assertion.submods.gce.project_number == "00000000000"

assertion.submods.gce.zone

Interagiert mit:

  • Arbeitslastoperator: Der Wert --zone.
String

Prüft, ob die VM in der angegebenen Zone ausgeführt wird.

Beispiel
assertion.submods.gce.zone == "us-central1-a"

assertion.submods.nvidia_gpu.cc_feature

Interagiert mit:

 Aufzählung

Prüft die von einer NVIDIA-GPU unterstützten Confidential Computing-Features. In Confidential Space wird nur der SPT-Modus (Single GPU Passthrough) unterstützt. Der Wert ist also immer SPT.

Weitere Informationen zur Unterstützung von NVIDIA Confidential Computing finden Sie unter NVIDIA Trusted Computing Solutions (PDF).

Beispiel
assertion.submods.nvidia_gpu.cc_feature == "SPT"

assertion.submods.nvidia_gpu.cc_mode

Interagiert mit:

 Aufzählung

Prüft den Status des Confidential Computing-Treibers von NVIDIA. Folgende Werte sind gültig:

  • OFF: Keine der NVIDIA Confidential Computing-Funktionen ist aktiv.
  • ON: Die Confidential Computing-Funktionen wurden für die NVIDIA H100-Hardware, ‑Firmware und ‑Software vollständig aktiviert.
  • DEVTOOLS: Die GPU befindet sich in einem partiellen Confidential Computing-Modus, der den Workflows des ON-Modus entspricht, aber die Sicherheitsmaßnahmen deaktiviert.
Beispiel
assertion.submods.nvidia_gpu.cc_mode == "ON"

assertion.submods.nvidia_gpu.gpus

Interagiert mit:

 Objekt-Array

Prüft die Ansprüche für jede attestierte NVIDIA-GPU. Confidential Space unterstützt nur eine einzelne GPU-Anforderung.

Ein gpus-Objekt sieht in etwa so aus:

{
  "hwmodel": "GCP_NVIDIA_H100",
  "ueid": "490457405999046854973671575630853621547794591064",
  "l4_serial_number": "1216669666319372030078",
  "driver_version": "570.00",
  "vbios_version": "96.00.9F.00.01"
}
Beispiele

Mit dem folgenden Code wird geprüft, ob das erste GPU-Hardwaremodell eine NVIDIA H100 ist, die auf Google Cloudausgeführt wird: 

assertion.submods.nvidia_gpu.gpus[0].hwmodel == "GCP_NVIDIA_H100"

Mit dem folgenden Code wird geprüft, ob die Attestierungsforderung GPU-bezogene Anforderungen enthält: 

has(assertion.submods.nvidia_gpu.gpus)