Key Management Service:Secrets management FAQs

How does KMS ensure the security of secrets?

KMS uses envelope encryption to protect secrets. When you create a secret, you specify a symmetric key in the KMS instance. KMS uses that key to generate a data key, encrypts the secret with the data key, and stores the encrypted secret in dedicated storage.

KMS does not encrypt secret metadata — the secret name, version number, and stage label are stored unencrypted.

When your application requests a secret, KMS authenticates it using Resource Access Management (RAM) or an application access point (AAP). After the authentication and permission check pass, KMS decrypts the secret and returns the plaintext to your application over TLS 1.2.

How is a secret encrypted?

KMS encrypts a secret via envelope encryption. The key used in envelope encryption is the one that you specify when you create the secret.

For more about envelope encryption, see Use KMS keys for envelope encryption.

"Your secret is being rotated, please try again later" when setting a rotation policy or triggering immediate rotation

This message appears because a rotation is already in progress. The expected duration depends on the secret type:

Secret status is unavailable or the API returns "Rejected.Unavailable"

The KMS instance that the secret belongs to has expired.

Renew the instance within 15 calendar days after expiration — after that, the instance is released. See Renewal policy.

If you no longer need the instance but may need the keys or secrets in it later, back it up before it is released. See Backup management.

Secrets created in KMS 1.0 are not visible in the KMS 3.0 console

The KMS 3.0 console displays only secrets that are managed in KMS instances. Secrets created in KMS 1.0 were created without a KMS instance, so they do not appear in the new console.

To view those secrets, switch to the old console.

RDS secret account verification fails

This usually means the ApsaraDB RDS account or ApsaraDB RDS instance associated with the secret has been deleted. Check whether both the ApsaraDB RDS account and the ApsaraDB RDS instance still exist in ApsaraDB RDS.

"You are not authorized to do this action" when creating a RAM secret

This error appears because the currently logged-on RAM account does not have permission to operate on cloud resources.

Send the authorization link to the RAM administrator — a RAM user with resource management permissions, or the Alibaba Cloud account holder — to complete the authorization. After authorization is complete, return to the RAM secrets creation page and click Refresh. You can then create the RAM secret.

For the specific authorization steps, see Step 1: Grant KMS the permissions to manage the AccessKey pair of a RAM user.

What permissions are required to retrieve a key-encrypted secret value via the API?

Both kms:GetSecretValue and kms:Decrypt are required. GetSecretValue retrieves the encrypted secret, and Decrypt is needed to decrypt it using the associated key.

Attach a policy similar to the following to the RAM user or RAM role making the API call:

{
  "Version": "1",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "kms:GetSecretValue",
      "kms:Decrypt"
    ],
    "Resource": [
      "acs:kms:${region}:${account}:secret/example-secret",
      "acs:kms:${region}:${account}:key/keyId-example"
    ]
  }]
}

Replace ${region}, ${account}, example-secret, and keyId-example with your actual values.

For instructions on attaching permission policies, see Grant permissions to a RAM user and Grant permissions to a RAM role.