Google Secret Manager und Cloud KMS zu STACKIT

Ein Secret hinein, eine Instanz heraus

Eine für diese Seite geschriebene Demo-Umgebung, am 4. November 2026 mit StackToIT bewertet, Google-Provider auf 8.4.0 festgelegt: ein Secret mit nutzerverwalteter Replika, Rotationsintervall und Benachrichtigungsthema, ein Service Account, der es liest, ein Schlüsselbund, ein Verschlüsselungsschlüssel und ein Signaturschlüssel. Links das Secret aus der Eingabe. Rechts die Instanz, die die Engine geschrieben hat; die Prüfkommentare darüber in der Datei sind hier weggelassen.

resource "google_secret_manager_secret" "db_password" {
  secret_id = "orders-db-password"

  replication {
    user_managed {
      replicas {
        location = "europe-west3"
      }
    }
  }

  rotation {
    next_rotation_time = "2027-01-01T00:00:00Z"
    rotation_period    = "7776000s"
  }

  topics {
    name = "projects/checkout-prod/topics/secret-rotation"
  }
}

resource "stackit_secretsmanager_instance" "migrated_secrets" {
  project_id = var.project_id
  name       = "migrated-secrets"
}

• Die Instanz ist alles, was der Entwurf für Secrets schreibt

  Der Lauf legt eine gemeinsame Secrets-Manager-Instanz namens migrated-secrets für alle migrierten Secrets an und nichts darin. Der Kommentar hält fest, dass jedes Secret von Hand als Schlüssel in der Instanz neu angelegt wird.

• Werte gelangen nie in den Entwurf

  Der Secret-Wert stammt aus einer sensiblen Variable der Quelle; der Lauf führt ihn als nicht übernommen, ebenso Secret-ID, Replikation, Rotation und Benachrichtigungsthema. Dieselbe Variable lässt den Quellstatus unaufgelöst, bis eine Variablendatei sie liefert; den Wert fragt der Lauf nie ab.

• Eine Region, keine Replikationswahl

  Laut Provider-Dokumentation ist Secrets Manager nur verfügbar, wenn die Provider-Region eu01 ist. Für den nutzerverwalteten Replika-Standort der Quelle gibt es keine Einstellung; der Lauf führt ihn unter den Einstellungen für eine Person.

Zwei Schlüssel, ein Schlüsselbund

Aus demselben Lauf. Links der Verschlüsselungsschlüssel mit geplanter Rotation und der hardwaregeschützte Signaturschlüssel. Rechts der Schlüsselbund und die beiden Schlüssel, die die Engine geschrieben hat; die Kommentare über den Blöcken sind hier weggelassen. Der Schlüsselbund trägt einen gemeinsamen Namen für alle migrierten Schlüssel.

resource "google_kms_crypto_key" "data" {
  name            = "data-encryption"
  key_ring        = google_kms_key_ring.checkout.id
  purpose         = "ENCRYPT_DECRYPT"
  rotation_period = "7776000s"

  version_template {
    algorithm        = "GOOGLE_SYMMETRIC_ENCRYPTION"
    protection_level = "SOFTWARE"
  }

  lifecycle {
    prevent_destroy = true
  }
}

resource "google_kms_crypto_key" "signing" {
  name     = "token-signing"
  key_ring = google_kms_key_ring.checkout.id
  purpose  = "ASYMMETRIC_SIGN"

  version_template {
    algorithm        = "EC_SIGN_P256_SHA256"
    protection_level = "HSM"
  }
}

resource "stackit_kms_keyring" "migrated" {
  project_id   = var.project_id
  display_name = "migrated-keys"
}

resource "stackit_kms_key" "data" {
  project_id   = var.project_id
  keyring_id   = stackit_kms_keyring.migrated.keyring_id
  display_name = "data-encryption"
  algorithm    = "aes_256_gcm"
  purpose      = "symmetric_encrypt_decrypt"
  protection   = var.kms_protection
  lifecycle {
    prevent_destroy = true
  }
}

resource "stackit_kms_key" "signing" {
  project_id   = var.project_id
  keyring_id   = stackit_kms_keyring.migrated.keyring_id
  display_name = "token-signing"
  algorithm    = "ecdsa_p256_sha256"
  purpose      = "asymmetric_sign_verify"
  protection   = var.kms_protection
}

• Algorithmus und Zweck wählt der Lauf

  Aus dem symmetrischen Schlüssel wird aes_256_gcm mit dem Zweck symmetric_encrypt_decrypt, aus dem Signaturschlüssel auf elliptischer Kurve ecdsa_p256_sha256 mit dem Zweck asymmetric_sign_verify. Die Provider-Dokumentation führt beide Werte.

• Schutz ist eine Variable ohne Standardwert

  Beide Schlüssel beziehen protection aus der Variable kms_protection, die keinen Standardwert hat. Der Lauf konnte den Hardware-Schutz des Signaturschlüssels nicht beibehalten und sagt das in einem Befund, der weiter unten steht.

• prevent_destroy wird übernommen, die Rotation nicht

  Der Lifecycle-Block des Verschlüsselungsschlüssels wird übernommen, weil er ein Terraform-Metaargument ist. Die 90-Tage-Rotation wird es nicht, und der Signaturschlüssel setzt in der Eingabe keine.

Die Befunde, auf die es ankommt

Drei Befunde so, wie assessment.json sie enthält (für Signaturschlüssel, Datenschlüssel und Secret; Nachweislisten gekürzt), dann die Zeilen des Entwurfs, die das Nicht-Übernommene benennen, dann die Konsolenzeilen des Laufs.

{"check_id":"kms-protection-level","severity":"warning","message":"Key material is protected by an HSM or held outside Google (EXTERNAL / EXTERNAL_VPC). STACKIT KMS keys are software-protected today: the API names the protection values \"software\" or \"hsm\", but the documentation says \"For now only Software is available.\", and there is no external-key option in the API. The protection level cannot be kept — decide whether software protection is acceptable, or keep the key outside STACKIT."
{"check_id":"kms-rotation","severity":"warning","message":"Automatic key rotation is scheduled (rotation_period). STACKIT KMS rotates a key on demand (Rotate key creates a new key version); automatic, scheduled rotation is not documented and stackit_kms_key has no rotation attribute — rotation becomes an operational process."
{"check_id":"secret-rotation","severity":"info","message":"Rotation notifications are configured. STACKIT Secrets Manager has no rotation schedule or notification, so rotation has to be driven by a job on STACKIT."

# NOT CARRIED (google_kms_crypto_key.data): rotation_period = 7776000s — scheduled rotation: stackit_kms_key (pinned provider) has no rotation attribute.
# NOT CARRIED (google_secret_manager_secret.db_password): replication, rotation, secret_id, topics — the secret is recreated as a key in the shared Secrets Manager instance by hand: its name, value (never copied into the draft) and access (grant it with Secrets Manager users or role bindings) are not generated.
# NOT CARRIED (google_secret_manager_secret_version.db_password): secret_data — the secret is recreated as a key in the shared Secrets Manager instance by hand: its name, value (never copied into the draft) and access (grant it with Secrets Manager users or role bindings) are not generated.

Source        8 resources · 4 units · visibility: Variable unresolved
Migration     4 drafted (of 4 units the draft considered)

• Hardware-Schutz bleibt nicht erhalten

  Der Lauf hält fest, dass STACKIT-KMS-Schlüssel heute softwaregeschützt sind und die API keine Option für externe Schlüssel kennt. Zwei Wege bleiben: Software-Schutz akzeptieren oder den Schlüssel außerhalb von STACKIT halten. Das ist eine Sicherheitsentscheidung, keine Zuordnung.

• Rotation wird zum Job

  STACKIT KMS rotiert einen Schlüssel auf Anforderung und erzeugt dabei eine neue Schlüsselversion; geplante Rotation ist nicht dokumentiert. Auch der Secrets Manager hat weder Rotationsplan noch Benachrichtigung. Beide Rotationen müssen Sie selbst anstoßen und betreiben.

• Alte Daten bleiben unter dem alten Schlüssel

  Laut Google-Dokumentation verschlüsselt Rotation vorhandene Daten nicht neu. Der Lauf sagt, Schlüssel werden neu erzeugt und nicht exportiert; mit einem Cloud-KMS-Schlüssel verschlüsselte Daten werden daher beim Datenumzug entschlüsselt und mit dem neuen Schlüssel neu verschlüsselt.

Wohin welches Objekt geht

Die Klassen sind RECONFIGURE mit mittlerer Konfidenz für Secret, beide Schlüssel und den Service Account. Die Berechtigungen gehören zur Einheit des Secrets beziehungsweise des Schlüssels.

Einen Wert und seinen Zugriff übertragen

Keine Engine-Ausgabe. Die Vault-Befehle folgen den STACKIT-Seiten zum Secrets Manager, die User-Ressource folgt der Provider-Dokumentation. Der Mount-Pfad ist die Instanz-ID.

# Written by hand from the STACKIT documentation, not engine output.
# 1. A secret is a key in the instance (mount path = instance ID)
vault kv put -mount=$INSTANCE_ID orders-db-password password=@db-password.txt

# 2. Version limit: billing counts versions; 0 means unlimited
vault write $INSTANCE_ID/config max_versions=10
vault kv metadata patch -mount=$INSTANCE_ID -max-versions=5 orders-db-password

# 3. Read back
vault kv get -mount=$INSTANCE_ID -field=password orders-db-password

# Written by hand from the provider documentation, not engine output.
resource "stackit_secretsmanager_user" "api_reads" {
  project_id    = var.project_id
  instance_id   = stackit_secretsmanager_instance.migrated_secrets.instance_id
  description   = "checkout-api, read only"
  write_enabled = false
}

• KV2-kompatibel, und nur KV2

  STACKIT nennt Kompatibilität mit HashiCorp Vault KV2 mit Secret-Versionierung und unterstützt keine andere Secrets-Engine. Ein Client mit anderer Vault-Engine zieht nicht unverändert um.

• Versionen kosten Geld

  Ein Secret hat standardmäßig unbegrenzt viele Versionen; bezahlt wird pro Version. Ein Limit an der Instanz oder am Secret begrenzt die Kosten; ein Absenken unter die aktuelle Anzahl löscht die ältesten Versionen.

• Backups stellen kein einzelnes Secret wieder her

  Laut STACKIT lassen sich einzelne Secrets nicht aus dem Backup zurückholen; es dient nur der Notfallwiederherstellung. Überschreiben Sie ein Secret, bleiben ältere Versionen erhalten, solange das Limit über eins liegt. Halten Sie eine externe Kopie der Werte, auf die Sie sich verlassen.

• Das Passwort ist unveränderlich

  Das Passwort eines Benutzers wird erzeugt und lässt sich nicht ändern; ein neues Passwort bedeutet einen neuen Benutzer. Der Provider kann einen Benutzer über rotate_when_changed durch einen Auslöser neu anlegen.

Die Migration der Reihe nach

1. 01

   Secrets, Schlüssel und Verbraucher inventarisieren

   Erfassen Sie jedes Secret, seine Versionen und die Identitäten mit Zugriff, jeden Schlüssel und seinen Zweck sowie jeden Dienst, der Secret Manager oder Cloud KMS aufruft. Der Lauf führt auf, was das Terraform deklariert; außerhalb davon angelegte Objekte sieht er nicht.

2. 02

   Zuerst den Schlüsselschutz entscheiden

   Entscheiden Sie je hardwaregestütztem Schlüssel, ob Software-Schutz genügt oder ob er außerhalb von STACKIT bleibt. Setzen Sie kms_protection erst danach.

3. 03

   Instanz, Schlüsselbund und Schlüssel anlegen

   Wenden Sie die erzeugten Blöcke in einem Testprojekt an. Prüfen Sie Algorithmus und Zweck jedes Schlüssels gegen die Nutzung in Ihrem Code.

4. 04

   Secrets übertragen

   Schreiben Sie jeden Wert mit einem Vault-Client, setzen Sie Versionslimits und legen Sie Benutzer mit Leserechten für die Verbraucher an. Ersetzen Sie den Secret-Manager-Client in den Anwendungen durch einen Vault-Client oder eine Injektion durch die Plattform, zum Beispiel External Secrets Operator auf SKE.

5. 05

   Die Neuverschlüsselung planen

   Mit einem Cloud-KMS-Schlüssel verschlüsselte Daten bleiben nur über Cloud KMS lesbar. Planen Sie Durchläufe zum Entschlüsseln und Neuverschlüsseln mit dem neuen Schlüssel und behalten Sie den Google-Schlüssel, bis der letzte Durchlauf geprüft ist.

6. 06

   Rotationsjobs bauen

   Rotieren Sie Schlüssel auf Anforderung aus einem geplanten Job und Secret-Werte aus einem Job, der eine neue Version schreibt. Halten Sie fest, wer jeden Job verantwortet.

Fragen von Sicherheitsteams

Quellen

• STACKIT Secrets Manager: FAQ
• STACKIT: Versionslimit für Secrets Manager festlegen
• STACKIT KMS
• STACKIT-Provider: secretsmanager_user
• STACKIT-Provider: kms_key
• Cloud KMS: Schlüsselrotation
• Google Cloud KMS: REST-Ressource cryptoKeyVersions