This topic describes the features of KMS Secrets Manager, such as secure secret storage, secure secret distribution, secret access control and usage auditing, and periodic secret rotation.
Secret management is one of the core demands of enterprises on IT system O&M security. Secrets Manager enables you to manage your secrets in a centralized manner throughout their lifecycle, such as creation, retrieval, updating, and deletion of your secrets. Users and applications retrieve secrets with a call to Secrets Manager API operations. This eliminates the need to hardcode sensitive information, such as account passwords, access keys, and server certificates. This prevents sensitive information leakage and permission-related risks.
Secure secret storage
You can use Secrets Manager to manage various types of secrets, which include but are not limited to access keys, API keys, server certificates and private keys, and account passwords. Secrets Manager encrypts your secrets by using one of the following encryption methods:
- Default encryption
If you do not specify a KMS customer master key (CMK) as the secret protection mechanism, Secrets Manager automatically generates a default encryption key to protect the secrets that belong to your Alibaba Cloud account. The default encryption key belongs to Secrets Manager. You do not need to manage the key, check it, audit its use, or pay for it.Note Secrets Manager allocates each Alibaba Cloud account with an independent KMS CMK to be used as the default encryption key.
- Custom encryption
You can specify a KMS CMK as the encryption key for secret objects. When you store plaintext secrets, Secrets Manager generates a data key to encrypt them and then stores the ciphertext secrets and ciphertext data key in persistent storage. You can manage the lifecycle of the CMK in KMS and view and audit the records of calling the CMK in ActionTrail. For more information about ActionTrail, see What is ActionTrail?.Note When you use the custom encryption method, take note of the following points:
- In addition to secret-related permissions, you must be granted the required permissions
on the encryption CMK:
- When you call the CreateSecret operation to create a secret or the PutSecretValue
operation to store a secret value into a secret object, you must have the kms:GenerateDataKey permission on the encryption CMK. Otherwise, Secrets Manager cannot call the GenerateDataKey
operation to generate a data key to encrypt the secret value.
For more information about the API operations, see:
- When you call the GetSecretValue operation to obtain a secret value, you must have
the kms:Decrypt permission on the encryption CMK. Otherwise, Secrets Manager cannot call the Decrypt
operation to decrypt the related data key and use the key to decrypt the ciphertext
of the secret value.
For more information about the API operations, see:
- When you call the CreateSecret operation to create a secret or the PutSecretValue operation to store a secret value into a secret object, you must have the kms:GenerateDataKey permission on the encryption CMK. Otherwise, Secrets Manager cannot call the GenerateDataKey operation to generate a data key to encrypt the secret value.
- You can manage the encryption CMK based on your business requirements. For example, you can disable or delete it. However, these operations have an impact on the use of secrets. For example, when the encryption CMK is in the Disabled or Pending Deletion state, you cannot call the PutSecretValue or GetSecretValue operation for the secrets protected by using this encryption CMK.
- In addition to secret-related permissions, you must be granted the required permissions on the encryption CMK:
Secure secret distribution
Secrets Manager enables you to distribute secrets in a secure manner. You do not need to configure secrets in plaintext as static information in code, configuration files, or databases. However, if you configure the secret names that are used in Secrets Manager for an application, the application can dynamically retrieve plaintext secrets. This feature is implemented as follows:
- The KMS server uses the specified KMS CMK to decrypt the ciphertext data key that is generated for secrets.
- Secrets Manager uses the plaintext data key to decrypt the ciphertext secrets.
- Secrets Manager returns the secrets to the KMS client by using HTTPS.
- The client decrypts the secrets.
Secret access control and usage auditing
- Controls access to secrets.
You can customize fine-grained permission policies to prevent unauthorized access and leakage.
- Audits the usage of secrets.
You can continuously monitor access to secrets and connect audit logs to SIEM solutions to improve threat detection and response capabilities.
Periodic secret rotation
Periodic secret rotation is an effective way to protect secrets. Secrets Manager enables secret managers and users (applications) to manage and distribute secrets in a publish/subscribe pattern. Secret managers rotate secrets on a schedule from the publish side, while users (applications) request new secrets on a schedule or on demand.
Secrets Manager optimizes the data model for secret rotation. Multiple versions of secret values can be stored in a single secret object. Stage labels are used to mark versions during automatic rotation. In most cases, the "current version" and "previous version" of secret values are stored. Secrets Manager provides two built-in stage labels ACSCurrent and ACSPrevious to mark the versions. You can switch between the versions based on their switching rules. If the KMS client calls the GetSecretValue operation and no stage label or version number is specified, the version that is marked with ACSCurrent is retrieved.