Secrets, Verschlüsselung und KMS-Migration zu STACKIT

Die Migration in der richtigen Reihenfolge

1. 01

   1. Schlüssel, Secrets und Verbraucher erfassen

   Listen Sie jeden Schlüssel auf, welche Ressourcen ihn nutzen (Datenbanken, Buckets, Secrets), und jedes Secret mit den Anwendungen, die es lesen. Der Lauf liest die Verknüpfungen aus dem Terraform; die Verbraucher eines Schlüssels sind also sichtbar, bevor etwas gebaut wird.

2. 02

   2. Keyring und Schlüssel anlegen

   STACKIT KMS gruppiert Schlüssel in Keyrings. Ein symmetrischer Schlüssel nutzt AES-256-GCM; daneben gibt es asymmetrische Zwecke sowie Signatur- und MAC-Zwecke. Derzeit steht nur Software-Schutz zur Verfügung, und die Schutzstufe ist eine Variable, die der Entwurf Ihnen überlässt.

3. 03

   3. Festlegen, wer den Schlüssel erreicht

   Der Zugriffsbereich des Schlüssels ist PUBLIC oder SNA. Der Quellschlüssel nennt kein Netzwerk, daher lässt der Lauf die Variable ohne Standardwert; bleibt sie leer, macht die STACKIT-API den Schlüssel öffentlich.

4. 04

   4. Daten neu verschlüsseln

   Mit dem alten Schlüssel geschützte Daten werden in den neuen Dienst geladen und dort verschlüsselt. Bei PostgreSQL Flex bindet der Entwurf die Instanz an den neuen Schlüssel; der Dienst akzeptiert diese Einstellung nur für freigeschaltete Konten, fragen Sie den Zugang also vor dem Apply an.

5. 05

   5. Secrets neu anlegen

   Der Entwurf legt eine Secrets-Manager-Instanz und einen schreibberechtigten Benutzer an; die Werte selbst schreibt ein API-Schritt aus einem Dokument, das Sie liefern. Löschen Sie den schreibenden Benutzer anschließend.

6. 06

   6. Instanz bei Bedarf mit einem Schlüssel verschlüsseln

   Secrets Manager kann die Werte einer Instanz mit einem KMS-Schlüssel verschlüsseln, gesetzt per API (im Portal lässt es sich noch nicht konfigurieren), mit einem Service Account, der mindestens die Rolle Secrets Manager Reader hat (Doku). Der Lauf hält fest: ein Schlüssel für alle Secret-Werte der Instanz, nicht einer je Secret.

7. 07

   7. Rotation ersetzen

   Keiner der beiden Dienste rotiert für Sie: KMS erzeugt eine neue Schlüsselversion, wenn Sie „Rotate key“ auslösen, laut Dokumentation eine kostenpflichtige Bestellung, und Secrets Manager hat keine automatische Rotation. Was die Rotationsfunktion der Quelle erledigte, wird Ihre Aufgabe, und der Lauf sagt das.

8. 08

   8. Anwendungen umstellen

   Anwendungen wechseln vom Cloud-SDK zu einem Vault-kompatiblen Client oder erhalten Secrets über die Plattform, zum Beispiel per External Secrets Operator auf SKE. Schlagen Sie Secrets unter ihrem neuen Pfad nach.

Ein Schlüssel und ein Secret, umgesetzt

Eine für diese Seite geschriebene Umgebung, von StackToIT am 4. November 2026 bewertet. Links: ein KMS-Schlüssel mit Alias, ein Secret mit Wert und Rotationsregel sowie ein Parameter. Rechts: die STACKIT-Blöcke aus security.tf (Prüfkommentare ausgelassen). Alias, Rotationsregel und Secret-Wert haben keinen Block; den Grund nennt der Entwurf in seinen Prüfkommentaren.

resource "aws_kms_key" "data" {
  description             = "data encryption key"
  enable_key_rotation     = true
  deletion_window_in_days = 30
}

resource "aws_kms_alias" "data" {
  name          = "alias/data"
  target_key_id = aws_kms_key.data.key_id
}

resource "aws_secretsmanager_secret" "db" {
  name       = "prod/orders/db"
  kms_key_id = aws_kms_key.data.arn
}

resource "aws_secretsmanager_secret_version" "db" {
  secret_id     = aws_secretsmanager_secret.db.id
  secret_string = jsonencode({ username = "orders", password = var.db_password })
}

resource "aws_secretsmanager_secret_rotation" "db" {
  secret_id           = aws_secretsmanager_secret.db.id
  rotation_lambda_arn = "arn:aws:lambda:eu-central-1:111122223333:function:rotate-db"

  rotation_rules {
    automatically_after_days = 30
  }
}

resource "aws_ssm_parameter" "feature_flags" {
  name  = "/prod/orders/feature-flags"
  type  = "SecureString"
  value = "checkout_v2=on"
}

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-key"
  algorithm    = "aes_256_gcm"
  purpose      = "symmetric_encrypt_decrypt"
  protection   = var.kms_protection
  access_scope = var.kms_access_scope == "SNA" ? "SNA" : null
}

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

resource "stackit_secretsmanager_user" "migration" {
  project_id    = var.project_id
  instance_id   = stackit_secretsmanager_instance.migrated_secrets.instance_id
  description   = "StackToIT migration user: writes the migrated secrets; delete it afterwards"
  write_enabled = true
}

• Ein Schlüssel, keine Kopie

  Der AWS-Schlüssel wird zu einem Keyring und einem AES-256-GCM-Schlüssel. Der Entwurf vermerkt, dass AWS-Schlüsselmaterial nicht exportierbar ist; mit dem alten Schlüssel verschlüsselte Daten werden also während der Migration neu verschlüsselt.

• Rotation und Alias werden nicht übernommen

  stackit_kms_key hat in der festgelegten Provider-Version weder ein Rotationsattribut noch einen Alias. Der Schlüssel rotiert nie von selbst, und Clients, die ihn per Alias ansprachen, müssen die neue Schlüssel-ID verwenden.

• Eine Instanz hält die Secrets

  Das Secret und der Parameter landen in einer Secrets-Manager-Instanz. Den Kundenschlüssel des Secrets setzt der Entwurf nicht an der Instanz, weil der Parameter in derselben Instanz keinen Schlüssel nennt; Sie setzen ihn, sobald die Schlüssel der Quellen entschieden sind.

• Der Schreiber ist ein temporärer Benutzer

  Der Migrationsbenutzer hat Schreibzugriff auf die Secrets Engine der ganzen Instanz. Die Beschreibung im Entwurf sagt selbst, dass er nach dem Schreiben der Secrets gelöscht werden soll.

Was zugeordnet wird und was bei Ihnen bleibt

Klassen, wie der Lauf sie entschieden hat. Die Schlüsselversion gehört bei STACKIT zum Decrypt-Aufruf, während der Quelldienst keine braucht.

Der Bucket ohne KMS-Modus

Aus demselben Lauf. Ein mit Kundenschlüssel verschlüsselter Bucket ist die einzige Einheit, die der Lauf ins Redesign schickt. Links: wie assessment.json ihn zusammen mit der Schlüssel-Einheit erfasst (ID, Klasse, Konfidenz und Ziel; den Befund fasst der Text unten zusammen). Rechts: der Bucket-Block, den der Entwurf schreibt, ohne jeden Schlüssel.

{
  "id": "aws_s3_bucket.exports",
  "class": "REDESIGN",
  "confidence": "LOW",
  "target": {
    "service": "STACKIT Object Storage"
  }
}
{
  "id": "aws_kms_key.data",
  "class": "RECONFIGURE",
  "confidence": "MEDIUM",
  "target": {
    "service": "STACKIT KMS"
  }
}

resource "stackit_objectstorage_bucket" "exports" {
  project_id = var.project_id
  name       = "acme-orders-exports"
}

• Was der Lauf gefunden hat

  Der Lauf hält fest, dass STACKIT Object Storage nur zwei Verschlüsselungsmodi dokumentiert: AES-256 im Ruhezustand und SSE-C. Bei einem Test in einem STACKIT-Projekt in eu01 am 16.10.2026 antwortete der Aufruf zum Setzen der Verschlüsselung für aws:kms mit 501 und ein Objekt-Put mit aws:kms mit 400; dass ein Vorgang aufgeführt ist, heißt also nicht, dass der Modus unterstützt wird.

• Zwei Optionen

  Plattformverschlüsselung im Ruhezustand akzeptieren, oder Clients liefern bei jeder Anfrage SSE-C-Schlüssel. Das Zweite ist ein Redesign der Verschlüsselung und jedes schreibenden Clients.

• Der Schlüssel bleibt woanders

  Der Entwurf verknüpft den Bucket nicht mit dem neuen Schlüssel. Entscheiden Sie vor dem Cutover, nicht danach, ob die Exporte sensibel genug für SSE-C sind.

Die Datenbank am neuen Schlüssel

Die PostgreSQL-Instanz desselben Laufs. Links: die AWS-Datenbank mit ihrem Kundenschlüssel. Rechts: der Instanz-Block, den der Entwurf schreibt, mit einem Encryption-Objekt, das auf den neuen Schlüssel, die Schlüsselversion und den Service Account zeigt.

resource "aws_s3_bucket_server_side_encryption_configuration" "exports" {
  bucket = aws_s3_bucket.exports.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.data.arn
    }
  }
}

resource "aws_db_instance" "orders" {
  identifier          = "orders-db"
  engine              = "postgres"
  engine_version      = "15.7"
  instance_class      = "db.m5.large"
  allocated_storage   = 100
  username            = "orders"
  password            = var.db_password
  storage_encrypted   = true
  kms_key_id          = aws_kms_key.data.arn
  skip_final_snapshot = true
}

resource "stackit_postgresflex_instance" "orders" {
  project_id = var.project_id
  name       = "orders-db"
  version    = "15"
  flavor_id  = "2.16"
  storage = {
    class = var.postgresflex_storage_class
    size  = 108
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl          = var.orders_allowed_cidrs
    access_scope = var.orders_access_scope == "SNA" ? "SNA" : null
  }
  encryption = {
    kek_key_id      = stackit_kms_key.data.key_id
    kek_key_version = tostring(var.data_key_version)
    kek_keyring_id  = stackit_kms_keyring.migrated.keyring_id
    service_account = var.data_service_account
  }
  retention_days = 32
}

• Variablen für die Identität

  Die Schlüsselversion und der Service Account, der die KMS-Vorgänge ausführt, sind Variablen, die Sie setzen. Der Lauf nennt, was das Objekt braucht, nicht welches Konto Sie nutzen.

• Erst Zugang, dann Apply

  Der Dienst akzeptiert dieses Objekt nur für freigeschaltete Konten und lehnt die Anfrage sonst ab. Der Lauf meldet das als Warnung an der Einheit.

• Daten ziehen per Dump oder Replikation um

  Die neue Instanz ist leer und von Anfang an verschlüsselt; wie sie gefüllt wird, behandelt das Daten-Playbook.

Entscheidungen, die bei Ihren Architekten liegen

• Öffentlicher Schlüssel oder Network-Area-Schlüssel

  Der Zugriffsbereich jedes Schlüssels, pro Schlüssel entschieden. Der Entwurf hat keinen Standardwert.

• Ein Schlüssel oder mehrere

  Secrets Manager nimmt einen Schlüssel je Instanz. Nutzten Secrets verschiedene Schlüssel, entscheiden Sie, welche sich eine Instanz teilen.

• Rotationsprozess

  Wer Schlüssel und Secrets rotiert, wie oft und mit welchem Job. KMS-Rotation erzeugt auf Anforderung eine neue Schlüsselversion; eine AppRole-Secret-ID rotieren Sie unterbrechungsfrei, indem Sie eine neue erzeugen, den Workload darauf umstellen, die Anmeldung prüfen und die alte löschen (Doku).

• Löschen alter Schlüssel

  Einen gelöschten Schlüssel entfernt STACKIT nach 30 Tagen. Behalten Sie die alten Cloud-Schlüssel, bis kein Backup und kein Snapshot sie mehr braucht; diese Regel ist Praxis, kein Befund des Laufs.

• Bucket-Verschlüsselung

  Plattformverschlüsselung oder SSE-C, wie oben.

Fragen zu Secrets und KMS

Quellen

• STACKIT KMS: Grundkonzepte
• STACKIT KMS: Schlüssel anlegen und verwalten
• STACKIT Secrets Manager: Funktionen und Servicepläne
• STACKIT Secrets Manager: KMS-Verschlüsselung
• STACKIT Secrets Manager: AppRoles konfigurieren und nutzen
• STACKIT-Terraform-Provider: Vault-Provider mit Secrets Manager