Google Secret Manager en Cloud KMS naar STACKIT

Eén secret erin, één instance eruit

Een demo-omgeving die voor deze pagina is geschreven en op 4 november 2026 door StackToIT is beoordeeld, met de google-provider vastgezet op 8.4.0: een secret met een door de gebruiker beheerde replica, een rotatieperiode en een notificatietopic, een service account dat het secret leest, een key ring, een versleutelingssleutel en een ondertekeningssleutel. Links: het secret uit de invoer. Rechts: de instance die de engine schreef; de reviewcommentaren erboven in het bestand zijn hier weggelaten.

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"
}

• De instance is alles wat het concept voor secrets schrijft

  De run maakt één gedeelde Secrets Manager-instance voor alle gemigreerde secrets, met de naam migrated-secrets, en niets erin. Het commentaar geeft aan dat elke secret handmatig opnieuw wordt aangemaakt als sleutel in de instance.

• Waarden komen nooit in het concept

  De waarde van het secret komt uit een gevoelige variabele in de bron, en de run noemt die als niet overgenomen, samen met de id van het secret, de replicatie, de rotatie en het notificatietopic. Dezelfde variabele laat de status van de bron onopgelost totdat een variabelenbestand de waarde aanlevert, en de run vraagt nooit om de waarde.

• Eén regio, geen keuze voor replicatie

  Volgens de providerdocumentatie is Secrets Manager alleen beschikbaar als de providerregio eu01 is. De door de gebruiker beheerde replicalocatie uit de bron heeft geen tegenhanger om in te stellen, en de run noemt die onder de instellingen voor een persoon.

Twee sleutels, één key ring

Uit dezelfde run. Links: de versleutelingssleutel met geplande rotatie en de ondertekeningssleutel met hardwarebeveiliging. Rechts: de key ring en de twee sleutels die de engine schreef; de commentaren boven elk blok zijn hier weggelaten. De key ring heeft één naam voor alle gemigreerde sleutels.

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
}

• Algoritme en doel worden voor u gekozen

  De symmetrische sleutel wordt aes_256_gcm met doel symmetric_encrypt_decrypt, en de ondertekeningssleutel op een elliptische curve wordt ecdsa_p256_sha256 met doel asymmetric_sign_verify. De providerdocumentatie noemt beide waarden.

• Beveiliging is een variabele zonder standaardwaarde

  Beide sleutels halen hun beveiliging uit de variabele kms_protection, die geen standaardwaarde heeft. De run kon de hardwarebeveiliging van de ondertekeningssleutel niet behouden en meldt dat in een bevinding, hieronder getoond.

• prevent_destroy gaat mee, rotatie niet

  Het lifecycle-blok van de versleutelingssleutel wordt overgenomen, omdat het een Terraform-metaargument is. De rotatieperiode van 90 dagen niet, en de ondertekeningssleutel stelt er in de invoer geen in.

De bevindingen die ertoe doen

Drie bevindingen zoals assessment.json ze bevat (voor de ondertekeningssleutel, de datasleutel en het secret; bewijslijsten ingekort), dan de regels van het concept die noemen wat niet is overgenomen, dan de consoleregels van de run.

{"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)

• Hardwarebeveiliging kan niet behouden blijven

  De run meldt dat STACKIT KMS-sleutels momenteel met software worden beveiligd en dat de API geen optie voor externe sleutels kent. Dat laat u twee keuzes: softwarebeveiliging accepteren of de sleutel buiten STACKIT houden. Dit is een beveiligingsbeslissing, geen koppeling.

• Rotatie wordt een job

  STACKIT KMS roteert een sleutel op verzoek, waardoor een nieuwe sleutelversie ontstaat, en geplande rotatie is niet gedocumenteerd. Secrets Manager kent ook geen rotatieschema of notificatie. Beide rotaties worden aangestuurd door iets wat u zelf laat draaien.

• Oude data blijft onder de oude sleutel

  De documentatie van Google geeft aan dat rotatie bestaande data niet opnieuw versleutelt. De run meldt dat sleutels opnieuw worden aangemaakt en niet geëxporteerd, dus data die met een Cloud KMS-sleutel is versleuteld, wordt tijdens de dataverplaatsing ontsleuteld en met de nieuwe sleutel opnieuw versleuteld.

Waar elk object naartoe gaat

De klassen zijn RECONFIGURE met zekerheidsniveau MEDIUM voor het secret, beide sleutels en het service account. De rechten maken deel uit van de eenheden van het secret en de sleutel waartoe ze behoren.

Een waarde en de toegang verplaatsen

Geen uitvoer van de engine. De Vault-commando's volgen de pagina's over STACKIT Secrets Manager; de gebruikersresource volgt de providerdocumentatie. Het mountpad is de instance-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
}

• Compatibel met KV2, en alleen KV2

  STACKIT geeft aan compatibel te zijn met HashiCorp Vault KV2 met versiebeheer voor secrets en ondersteunt geen andere secrets engine. Een client die een andere Vault-engine gebruikt, verhuist niet ongewijzigd.

• Versies kosten geld

  Een secret heeft standaard een onbeperkt aantal versies en u betaalt per versie. Een limiet op de instance of op een secret begrenst de kosten; een limiet verlagen onder het huidige aantal verwijdert de oudste versies.

• Back-ups herstellen geen afzonderlijke secret

  STACKIT geeft aan dat afzonderlijke secrets niet uit een back-up kunnen worden hersteld, omdat die alleen voor disaster recovery dient. Overschrijft u een secret, dan blijven oudere versies bestaan zolang de limiet boven één ligt. Bewaar een externe kopie van waarden waarop u steunt.

• Het wachtwoord kan niet worden gewijzigd

  Het wachtwoord van een gebruiker wordt gegenereerd en kan niet worden gewijzigd; een nieuw wachtwoord betekent een nieuwe gebruiker. De provider kan een gebruiker via rotate_when_changed bij een trigger opnieuw aanmaken.

De migratie in volgorde

1. 01

   Inventariseer secrets, sleutels en gebruikers

   Maak een lijst van elke secret, de versies, de gebruikers ervan, elke sleutel, het doel en elke dienst die Secret Manager of Cloud KMS aanroept. De run noemt wat de Terraform declareert; objecten die daarbuiten zijn gemaakt, ziet de run niet.

2. 02

   Bepaal eerst de beveiliging van sleutels

   Bepaal voor elke sleutel met hardwareondersteuning of software-beveiliging acceptabel is, of dat de sleutel buiten STACKIT blijft. Stel kms_protection in zodra dat is besloten.

3. 03

   Maak de instance, key ring en sleutels aan

   Pas de gegenereerde blokken toe in een testproject. Toets algoritme en doel van elke sleutel aan hoe uw code die gebruikt.

4. 04

   Verplaats secrets

   Schrijf elke waarde met een Vault-client, stel versielimieten in en maak gebruikers met alleen leesrechten voor de afnemers. Vervang de Secret Manager-client in applicaties door een Vault-client of door injectie door het platform, bijvoorbeeld External Secrets Operator op SKE.

5. 05

   Plan de herversleuteling

   Data onder een Cloud KMS-sleutel blijft alleen leesbaar via Cloud KMS. Plan rondes van ontsleutelen en versleutelen met de nieuwe sleutel, en houd de Google-sleutel totdat de laatste ronde is geverifieerd.

6. 06

   Bouw de rotatiejobs

   Roteer sleutels op verzoek vanuit een geplande job en roteer waarden van secrets vanuit een job die een nieuwe versie schrijft. Leg vast wie eigenaar is van elke job.

Vragen die securityteams stellen

Bronnen

• FAQ van STACKIT Secrets Manager
• STACKIT: de versielimiet voor Secrets Manager instellen
• STACKIT KMS
• STACKIT-provider: secretsmanager_user
• STACKIT-provider: kms_key
• Cloud KMS: sleutelrotatie
• Google Cloud KMS: REST-resource cryptoKeyVersions