This topic answers common questions about using secrets.
Questions
Secret security in KMS
When you create a secret, you must specify a symmetric key in the same instance to encrypt the secret. KMS uses this key to perform envelope encryption on the secret value and stores the encrypted result in your dedicated storage space.
KMS does not encrypt metadata such as the secret name, version number, or version staging labels.
After authentication and authorization, KMS decrypts the secret and securely transmits it to your application over TLS 1.2.
How secrets are encrypted
KMS encrypts secret values using envelope encryption. The encryption key is the one you specify when you create the secret. For more information about envelope encryption, see Use KMS keys for envelope encryption.
The "Your secret is being rotated, please try again later" message
|
Type |
Possible cause |
|
RAM secret |
The RAM secret is being rotated. Rotating a RAM secret takes a period of time to complete, known as the rotation window. For periodic automatic rotation, the rotation window is approximately 48 hours. For an immediate rotation, the window is the duration that you set. If the rotation does not complete within the rotation window, check in Resource Access Management (RAM) to see if the RAM user still exists. |
|
ApsaraDB for RDS secret |
Normally, an ApsaraDB for RDS secret rotation completes immediately. If the rotation takes more than 2 minutes, check the status of the ApsaraDB for RDS instance and the associated account. |
|
ECS secret |
Normally, an ECS secret rotation completes immediately. If the rotation takes more than 2 minutes, check the status of the ECS instance and the associated account. |
The unavailable status or "Rejected.Unavailable" error
The KMS instance that contains the secret has expired.
You must renew the KMS instance within 15 days of its expiration. Otherwise, the instance will be released. For more information, see Renewal policy.
If you do not plan to use the KMS instance for now but may need its keys or secrets in the future, we recommend that you back them up. For more information, see Backup management.
Cannot find a secret in the new console
The new console displays only secrets that are managed in KMS instances.
Previously, users on older versions of KMS could create secrets without a KMS instance. These secrets are not supported and cannot be viewed in the new console. To view these secrets, go to the old console.
RDS secret account verification failure
This usually occurs because the database account or instance associated with the ApsaraDB for RDS secret has been deleted. Verify that the account and instance still exist in ApsaraDB for RDS.
"You are not authorized" error when creating a RAM secret
This error occurs because the current RAM user or role lacks the required permissions to manage cloud resources. Send the authorization link to a RAM administrator, such as a RAM user with resource management permissions or the Alibaba Cloud account, to grant the permissions. After the administrator grants the permissions, return to the page for creating the RAM secret and click Refresh or reload the page. For more information, see Step 1: Grant KMS the permissions to manage the AccessKey pair of a RAM user.
Required permissions to retrieve a secret value
Because secrets are stored encrypted in KMS, you also need the permission to use the key for decryption (Decrypt). The following policy grants the minimum permissions required to retrieve a secret value through an API call, but not from the console. The following is a sample permission policy:
{
"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"
]
}]
}For more sample permission policies, see Custom permission policy examples. To learn how to grant permissions to a RAM user or RAM role, see Grant permissions to a RAM user and Grant permissions to a RAM role.