Huawei KMS and CSMS to STACKIT KMS and Secrets Manager

Two keys and a secret, assessed

A small Huawei Cloud estate written for this page and assessed by StackToIT on 4 November 2026. Left: a symmetric key, a signing key and a secret that names the first key. Right: the result recorded for the key and for the secret, excerpts of assessment.json with the values as the run wrote them.

resource "huaweicloud_kms_key" "data" {
  key_alias        = "payments-data"
  key_algorithm    = "AES_256"
  key_description  = "Encrypts payment exports"
  pending_days     = "30"
  rotation_enabled = true
}

resource "huaweicloud_kms_key" "signing" {
  key_alias     = "payments-signing"
  key_algorithm = "RSA_2048"
  key_usage     = "SIGN_VERIFY"
  pending_days  = "30"
}

resource "huaweicloud_csms_secret" "db" {
  name        = "payments-db"
  secret_text = jsonencode({ username = "app", password = var.db_password })
  kms_key_id  = huaweicloud_kms_key.data.id
}

{
  "id": "huaweicloud_kms_key.data",
  "result": {
    "class": "RECONFIGURE",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT KMS"
    },
    "reason": "A KMS key becomes a STACKIT KMS key. Key material of the source does not move, so data encrypted with it is re-encrypted."
  }
}

{
  "id": "huaweicloud_csms_secret.db",
  "result": {
    "class": "RECONFIGURE",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT Secrets Manager"
    },
    "reason": "A CSMS secret becomes a secret in STACKIT Secrets Manager. Values are moved by an operator, and applications change how they read them."
  }
}

• Key material stays behind

  The key is classified RECONFIGURE with MEDIUM confidence. The run states that the key material of the source does not move, so data encrypted with it is re-encrypted on the target.

• Values are moved by a person

  The secret is also RECONFIGURE. Its value is written by an operator, and applications change how they read it. The assessment never asks for a secret value and never carries one.

• Named, not decided

  For the first key the run lists key_algorithm, key_alias, key_description, pending_days and rotation_enabled as settings your architects carry across. For the secret it lists kms_key_id, name and secret_text.

The order the run proposes, and who owns it

Because the database secret names the data key, it waits for it. The other three units start together. The second pane shows a gap worth closing early.

## Wave 1 — 3 unit(s)

| Unit | Class | Target |
|---|---|---|
| `huaweicloud_csms_secret.api` | RECONFIGURE / MEDIUM | STACKIT Secrets Manager |
| `huaweicloud_kms_key.data` | RECONFIGURE / MEDIUM | STACKIT KMS |
| `huaweicloud_kms_key.signing` | RECONFIGURE / MEDIUM | STACKIT KMS |

## Wave 2 — 1 unit(s)

| Unit | Class | Target |
|---|---|---|
| `huaweicloud_csms_secret.db` | RECONFIGURE / MEDIUM | STACKIT Secrets Manager |

4 manual steps have no owner role: no role follows from the plan for it, so nobody is named to carry it out. Assign an owner to each; until then the migration is not ready (each shows "Owner assignment required" under Who below).

- the owner table has no role for the category "security" of the unit (4 manual steps): the manual migration of huaweicloud_csms_secret.api, the manual migration of huaweicloud_csms_secret.db, the manual migration of huaweicloud_kms_key.data, the manual migration of huaweicloud_kms_key.signing

## Manual steps

• Wave 1 and wave 2

  Both keys and the standalone secret are in wave 1. The secret that references huaweicloud_kms_key.data is in wave 2. Waves are a starting point for your schedule, not a schedule.

• Nobody is named for security

  The owner table of this build has no role for the category security, so all four manual steps read Owner assignment required. Name an accountable person for keys and secrets before the first step starts.

The migration in eight steps

1. 01

   1. Inventory what each key protects

   The Terraform shows the keys and the secrets that reference them. It does not show every service that encrypts with a key. List those consumers from the source account; each one is a re-encryption task.

2. 02

   2. Map every key to a STACKIT algorithm

   STACKIT’s KMS concepts page lists AES 256 GCM for symmetric encryption, RSA OAEP with 2048, 3072 and 4096 bits (and 4096 bits with SHA-512) for asymmetric encryption, HMAC SHA256, SHA384 and SHA512 for message authentication codes, and ECDSA on P-256, P-384 and P-521 for signatures. The demo’s signing key is RSA_2048 with SIGN_VERIFY: STACKIT lists no RSA signing algorithm, so it becomes an ECDSA key and every verifier changes with it. SM4 and SM2 keys have no entry at all; decide the replacement before you build anything.

3. 03

   3. Create the key ring and keys

   On STACKIT a key version is either created by the system or imported through a wrapping key. Generate new keys by default. Import only key material you created yourself outside Huawei Cloud: Huawei’s FAQ states that a CMK cannot be exported from its KMS, and the run likewise assumes the material does not move.

4. 04

   4. Re-encrypt the data

   Switch each consumer to the new key and re-encrypt what it holds. This is the long step, and it is why the old key must outlive the cutover.

5. 05

   5. Create the Secrets Manager instance and a user

   Clients authenticate with the userpass method against the regional endpoint. Plan one user per application, not one shared user.

6. 06

   6. Write the secrets in wave order

   Write each value yourself, from the source of truth and not from the Terraform. A JSON secret such as the database credentials maps naturally to the key-value pairs of a Secrets Manager secret.

7. 07

   7. Change how applications read

   Secrets Manager is compatible with Vault KV version 2. Applications swap the Huawei SDK call for a Vault client call and renew their token, which lives 15 minutes by default.

8. 08

   8. Retire the old keys last

   Huawei schedules key deletion after a waiting period of 7 to 1096 days. Set it once the last consumer is re-encrypted and verified, and treat a deleted key as unrecoverable.

How each setting travels

Rows follow the demo input. Huawei CSMS secrets without a chosen key use the default key csms/default.

Writing and reading a secret on STACKIT

The commands below are copied from STACKIT’s page on the Vault CLI, in the order it lists them. Replace the placeholders, and replace the example path app1/mysecret and the pair foo=bar with your own (for example payments/db with username and password); the Secrets Manager ID takes the place of the usual mount name.

export VAULT_ADDR=https://prod.sm.eu01.stackit.cloud
vault login -method=userpass username=<username> password="<password>"

vault kv put -mount=<secrets-manager-id> app1/mysecret foo=bar
vault kv get -mount=<secrets-manager-id> app1/mysecret

• Versions cost money

  STACKIT charges per secret version, and a secret may have an unlimited number of them. Set a version limit on the instance or the secret.

• Deleted means gone

  STACKIT states that it cannot restore individual secrets or secrets engines. Keep the source secret until the new one has served real traffic.

Where Huawei and STACKIT differ

• Rotated secrets

  Huawei distinguishes shared secrets from rotated ones, and rotated ones cover services such as RDS, GaussDB and DCS Redis. The STACKIT Secrets Manager FAQ describes versioned storage and mentions no automatic rotation; if you rely on one today, plan to rebuild it.

• Size and format

  A CSMS secret can be up to 64 KB. The STACKIT pages read for this tutorial state no size limit, so check yours before you move large values.

• Key deletion is final

  Huawei’s provider accepts pending_days from 7 to 1,096 days. Treat the deletion as final and do not schedule it before re-encryption is verified.

• Algorithms narrow

  Huawei’s provider accepts AES_256, SM4, RSA_2048, RSA_3072, RSA_4096, EC_P256, EC_P384 and SM2 keys. STACKIT’s set differs: RSA is for encryption only, EC is for ECDSA signatures, and SM4 and SM2 are absent, so some keys have a design decision rather than a mapping.

What to change before you apply anything

• Assign owners

  Add an accountable person for the four security steps, as the manual-steps file demands.

• Answer the region

  The run asks for target.region (eu01 or eu02) and counts it as the request that blocks the draft. Copy it from inputs-template.yaml into your inputs file and pass that with --inputs.

• Keep secret values out of the repository

  The demo ships placeholders in a variable file only so the assessment can complete. Real values belong in your secret store, never in Terraform files.

• Pin the provider

  The run warns that no lock file pins the huaweicloud provider. Commit .terraform.lock.hcl.

Questions security teams ask

Sources

• STACKIT KMS: Concepts
• STACKIT KMS: Create and manage keys
• STACKIT Secrets Manager: FAQ
• STACKIT Secrets Manager: CLI and API
• Huawei Cloud: Creating a Secret (CSMS)
• Terraform Registry: huaweicloud_kms_key (1.100.0)
• Huawei Cloud DEW FAQ: Can I Export a CMK from KMS?