Secrets Manager allows you to manage your secrets throughout their lifecycle and allows applications to use secrets in a secure and efficient manner. This helps prevent sensitive data leaks that are caused by hardcoded secrets.
Benefits
Leaks of sensitive data, such as passwords of the accounts that are used to access databases and servers, SSH keys, and AccessKey pairs, are the main threats to data security. To reduce the risks of data leaks, you must effectively protect and periodically rotate secrets. When you protect and rotate your secrets, you may encounter the following issues:
To protect secrets, you must encrypt the secrets. The process of application deployment becomes longer, which leads to high research and development (R&D) and Operations and Maintenance (O&M) costs. The process is also difficult to enforce.
Lack of software for automatic secret rotation. Manual secret rotation requires the collaboration of multiple roles such as security, O&M, and R&D roles. A manual secret rotation process is difficult to develop and implement and is prone to errors.
Lack of rapid emergency response to secret leak events. As a result, system errors may occur when secret leak events are processed.
Lack of centralized management for the secrets that are required by cloud resources. As a result, large-scale management cannot be achieved, and management costs are high.
Secrets Manager provides the following benefits:
Encrypts and manages secrets to prevent sensitive data leaks due to hardcoded secrets. This improves data security.
Provides Secrets Manager Client for secure and convenient access. This way, applications can use secrets in a codeless or low-code way.
Delivers emergency response capabilities. Applications are not affected when you immediately rotate your secrets.
Allows you to rotate dynamic secrets at a high frequency. This shortens the validity period of each secret and reduces the risks of secret leaks.
Allows you to use API operations and O&M orchestration tools such as Terraform and Resource Orchestration Service (ROS). This meets the requirements for centralized and large-scale security management.
Scenarios
In this section, the account of a database is used as the managed secret.
A system administrator configures an account consisting of a username and a password in a database, which is used to access the database from the application MyApp.
The system administrator creates a secret MyDbCreds in KMS to store the username and password.
When MyApp wants to access the database, MyApp sends a request for MyDbCreds to KMS.
KMS reads the username and password in ciphertext, decrypts the username and password, and then returns the plaintext to MyApp over HTTPS.
MyApp reads and parses the plaintext that is returned by KMS to obtain the username and password. Then, MyApp uses the username and password to access the database.
In this process, MyApp calls an API operation of KMS to obtain the username and password. This prevents sensitive data leaks due to hardcoded secrets. The following figure shows the differences between hardcoded secrets and calling API operations of KMS.
Features
Secret encryption: KMS uses specified keys to encrypt secrets.
ImportantYour key and secret must belong to the same KMS instance. The key must be a symmetric key. For more information about the symmetric keys supported by KMS, see Key types and specifications.
Dynamic use: Your applications can dynamically read secrets by using Secrets Manager SDK and use the up-to-date secrets.
Automatic rotation: KMS supports out-of-the-box automatic rotation for secrets of specific types. You can also rotate secrets on a custom schedule by using Function Compute.
Access control and usage audit: You can use Resource Access Management (RAM) to control access to secrets. You can use ActionTrail to audit operations such as secret rotation and reading.
Supported types of secrets
KMS allows you to manage the following types of secrets: generic secrets, RAM secrets, ApsaraDB RDS secrets, and Elastic Compute Service (ECS) secrets.
Secret type | Description | Rotation | References |
Generic secret | Generic secrets are basic secrets that can be managed by KMS. You can use generic secrets to store sensitive data such as accounts, AccessKey pairs, OAuth secrets and tokens, and API keys. | You can rotate your secrets on a custom schedule by using Function Compute. You can also immediately rotate your secrets by specifying new values for secrets. | |
RAM secret | RAM secrets store AccessKey pairs of RAM users. An AccessKey pair consists of an AccessKey ID and AccessKey secret. The AccessKey pair is used to authenticate the RAM user when the RAM user is used to call Alibaba Cloud API operations. KMS allows you to manage RAM secrets. You can enable automatic periodic rotation for RAM secrets or immediately rotate RAM secrets to reduce the risks of secret leaks. If you use the RAM secret plug-in, you can obtain RAM secret values in a more convenient manner when you develop an application. | You can rotate your secrets on a custom schedule. You can also immediately rotate your secrets. | |
ApsaraDB RDS secret | ApsaraDB RDS secrets are the usernames and passwords of databases on an ApsaraDB RDS instance. KMS allows you to manage ApsaraDB RDS secrets. You can enable automatic periodic rotation for ApsaraDB RDS secrets or immediately rotate ApsaraDB RDS secrets to reduce the risks of secret leaks. | You can rotate your secrets on a custom schedule. You can also immediately rotate your secrets. | |
ECS secret | ECS secrets are the passwords and public and private keys that are used for authentication when you log on to ECS instances. KMS allows you to manage ECS secrets. You can enable automatic periodic rotation for ECS secrets or immediately rotate ECS secrets to reduce the risks of secret leaks. This way, strong passwords and public and private keys are used as ECS logon credentials, and the risks of data leaks are reduced. | You can rotate your secrets on a custom schedule. You can also immediately rotate your secrets. |