Azure Key Vault to STACKIT Secrets Manager and KMS

One vault in, one Secrets Manager instance out

A demo estate written for this page and assessed by StackToIT on 4 November 2026: a standard-tier vault with RBAC authorization and purge protection, one secret, one RSA key and one certificate. Left: the vault, the secret and the key from the input (the certificate block is left out). Right: the resource block of the STACKIT Terraform the engine wrote; the review comments above it in the file are left out here.

resource "azurerm_key_vault" "shop" {
  name                       = "kv-shop-gwc"
  location                   = azurerm_resource_group.sec.location
  resource_group_name        = azurerm_resource_group.sec.name
  tenant_id                  = data.azurerm_client_config.current.tenant_id
  sku_name                   = "standard"
  soft_delete_retention_days = 30
  purge_protection_enabled   = true
  rbac_authorization_enabled = true
}

resource "azurerm_key_vault_secret" "db_password" {
  name         = "orders-db-password"
  value        = var.db_password
  key_vault_id = azurerm_key_vault.shop.id
}

resource "azurerm_key_vault_key" "data" {
  name         = "data-encryption-key"
  key_vault_id = azurerm_key_vault.shop.id
  key_type     = "RSA"
  key_size     = 2048
  key_opts     = ["decrypt", "encrypt", "wrapKey", "unwrapKey"]
}

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

• The instance is all the draft writes

  The run creates the Secrets Manager instance and nothing inside it. The comments state that no setting of the vault, its name, tenant, SKU, access rules, network rules or retention, is generated, and that each secret is recreated as a key in the instance.

• Values never enter the draft

  The secret value comes from a sensitive variable in the source. The run writes no value, and the critical setting about vault objects says a person puts each secret into the instance.

• Keys and certificates are decisions

  A key's type, size and operations are chosen on a KMS key; certificates have no STACKIT counterpart for issuance or renewal. The draft names both as not carried.

How the run classifies the vault

Excerpt of assessment.json for the vault unit (id, class, confidence and target of its result, values as written), then selected comment lines of terraform/security.tf, verbatim.

{
  "id": "azurerm_key_vault.shop",
  "result": {
    "class": "RECONFIGURE",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT Secrets Manager (+ KMS for keys)",
      "resources": [
        "stackit_secretsmanager_instance",
        "stackit_secretsmanager_user"
      ]
    }
  }
}

# NOT CARRIED (azurerm_key_vault_key.data): key_opts, key_size = 2048, key_type = RSA, key_vault_id, name = data-encryption-key — a setting of azurerm_key_vault.shop: recreate its secrets as secrets in the Secrets Manager instance; none of the vault's settings (name, tenant, SKU, access policies, network rules, retention) is generated.
# NOT CARRIED (azurerm_key_vault_secret.db_password): key_vault_id, name = orders-db-password, value — a setting of azurerm_key_vault.shop: recreate its secrets as secrets in the Secrets Manager instance; none of the vault's settings (name, tenant, SKU, access policies, network rules, retention) is generated.
# azurerm_key_vault.shop: WARNING kv-certificates: Certificates (possibly auto-renewed by Key Vault) are stored in the vault; STACKIT has no certificate-lifecycle service, so renewal moves to the load balancer certificate upload or cert-manager.
# azurerm_key_vault.shop: WARNING kv-access-model: Access is granted to Entra principals (access policies or Azure RBAC); on STACKIT access is granted to Secrets Manager users or service accounts, so every consumer gets new credentials.

• RECONFIGURE, not a copy

  The class is RECONFIGURE with MEDIUM confidence. Applications switch from the Key Vault SDK or references to a Vault client or injection by the platform, and from Entra principals to Secrets Manager users.

• Ten open settings, three owners

  decisions.json holds ten open critical settings in three records. The Identity Architect owns five: access model, deletion protection, resource-group scope, tenant and vault objects. The Platform Architect confirms four names, of the vault, the secret, the key and the certificate; the Security Architect owns the certificates. Deletion protection is refused outright: the run finds no STACKIT counterpart, so a redesign or an accepted difference has to settle it.

Where each Key Vault object goes

Classes and wording as the run decided them. The secret, key and certificate are part of the vault unit.

The migration in order

1. 01

   Inventory the vault

   List the secrets, keys and certificates, and the consumers of each. The run lists the objects of the Terraform; objects created outside it are not seen.

2. 02

   Create the instance

   Apply the generated instance in a test project first. The provider documents the Secrets Manager resources only for a provider configured with default_region eu01.

3. 03

   Move secrets

   STACKIT states compatibility with HashiCorp Vault KV2 and one secrets engine. Write each value with the Vault CLI as STACKIT’s how-to shows, for example vault kv put -mount=<instance ID> orders-db-password value=…, and set a version limit, because billing counts secret versions.

4. 04

   Create keyrings and keys

   Create a keyring, then each key with an algorithm and purpose KMS lists. KMS accepts imported key material, but the run says non-exportable Azure keys are re-created.

5. 05

   Replace certificate handling

   Upload to the load balancer or run cert-manager on a cluster. Plan renewal as work, since nothing renews the certificate for you.

6. 06

   Issue new access

   Give each consumer a Secrets Manager user. The password is generated, cannot be changed, and a new one needs a new user.

Keyring, key and a read-only user, by hand

• Keyring first

  stackit_kms_keyring needs a project_id and a display_name. The draft writes no keyring; you add it once the key decisions are made.

• Then the key

  stackit_kms_key needs keyring_id, display_name, protection, algorithm and purpose; the provider's example uses the protection software. For the demo's RSA 2048 encryption key the closest listed values are rsa_2048_oaep_sha256 with the purpose asymmetric_encrypt_decrypt.

• Check the key fit

  The Azure key allows encrypt, decrypt, wrapKey and unwrapKey. As of November 2026 STACKIT KMS lists aes_256_gcm and RSA OAEP variants (2048, 3072 and 4096 bit with SHA-256, 4096 bit with SHA-512) for encryption and decryption. Whether one of them meets the way your code wraps data keys is yours to verify before any cutover.

• Generate or import

  KMS lets you decide per key or key version whether the material is generated or imported, and states that exporting keys is not intended. Keys that never leave KMS are re-created, as the run says for non-exportable Azure keys.

• A read-only consumer

  stackit_secretsmanager_user with write_enabled set to false gives an application read access only. Its password is generated by the service and returned as a sensitive attribute.

• Destroy does not delete

  On destroy the provider schedules a key for deletion and only removes a keyring from the state. Treat both as long-lived resources.

Questions security teams ask

Sources

• STACKIT Secrets Manager
• STACKIT Secrets Manager FAQ
• STACKIT KMS
• STACKIT provider: kms_key
• STACKIT provider: secretsmanager_user
• Azure Key Vault overview
• STACKIT docs: Vault CLI basics of Secrets Manager