Help Center/ Data Encryption Workshop/ User Guide/ CSMS/ Overview
Updated on 2026-04-28 GMT+08:00
View PDF
Share

Overview

A secret is used to verify identity and authorize access. In the information security and identity authentication fields, a secret is a key mechanism to ensure that only authorized users can access the system, resources, or services. Secrets include usernames and passwords, digital certificates, key pairs (public and private keys), tokens, biometric information, one-time passwords (OTPs), and smart cards.

Why Do I Need CSMS?

The leakage of secrets, including database account passwords, server account passwords, SSH keys, and access keys, is a primary threat to data security today. To mitigate the risk of data breaches, appropriate secret protection and automatic rotation are essential. The CSMS of DEW provides the following benefits:

  • DEW uses high-security cryptographic algorithms to encrypt and store secret values, preventing secret leakage and high-value asset leakage caused by hardcoding, thereby improving data security.
  • Clients can access workloads securely and with ease. Applications can dynamically fetch secrets through no-code or low-code methods.
  • Emergency response capabilities ensure your applications and workloads remain unaffected during immediate secret rotations.
  • Fully dynamic secrets are frequently rotated. This minimizes the validity window of a secret, lowering the risk of brute-force attacks.
  • You can use O&M orchestration tools, including APIs and Terraform, to implement centralized, large-scale security management.

Video Tutorial

The following video introduces how to use CSMS.

Supported Secret Types

DEW supports shared secrets and rotated secrets. The differences between them are as follows.

Table 1 Supported secret types

Type

Description

Subtype

Scenario

Support Automatic Rotation

Shared secret

Full lifecycle management is supported for customized secrets in different scenarios. You can use CSMS to centrally manage, retrieve, and securely store various types of secrets, such as database account passwords, server passwords, SSH keys, and access keys. Multiple versions can be managed, so you can rotate secrets.

-

Supports full lifecycle management of customized secrets in different scenarios.

No. Manual rotation is required.

Rotated secret

Database secret leakage is the main cause of data leakage. CSMS supports RDS and TaurusDB secrets hosting, as well as automatic and manual rotation, meeting various database secret management scenarios and reducing security risks faced by service data.
  • RDS secrets: MySQL, PostgreSQL, SQLServer, MariaDB, and TaurusDB
  • TaurusDB secrets: TaurusDB instance, formerly GaussDB(for MySQL) instance
  • GaussDB secrets: GaussDB instance
  • APIG secrets: APIG instance

The application scenarios of the secrets are as follows:

  • RDS secrets: Automatically hosts Huawei Cloud RDS database secrets.
  • TaurusDB secrets: Huawei Cloud TaurusDB secrets are automatically hosted.
  • GaussDB secrets: Huawei Cloud GaussDB secrets are automatically hosted.
  • APIG secrets: APIG secrets are automatically hosted.

Yes. Single-user and dual-user rotation models are supported.

Secret Composition

A secret consists of metadata and one or more secret versions. You can check secret details on the secret management page.

  • Metadata

    It contains a secret name, secret ID, creation time, secret type, encryption key, and other information.

  • Secret version

    A secret can have multiple versions. Each secret version contains a version number, version status, and secret value.

    • Built-in version statuses:
      • SYSCURRENT: Current version of a secret. It indicates the status of the latest secret value.
      • SYSPREVIOUS: Previous version of a secret.
      • SYSPENDING: Pending version status. It is generated during rotation and will not be displayed after rotation is complete.
      • When you call an API to obtain a secret value, the value corresponding to SYSCURRENT is returned.
      • Built-in version statuses act as pointers. For example, when you create the first version (v1), it is automatically assigned the SYSCURRENT status. When you add a second version (v2), the SYSCURRENT pointer moves to v2, and the status of v1 automatically changes to SYSPREVIOUS.
    • Custom version statuses: You can define multiple statuses for a secret version.
  • Secret value: The secret information you store, which can be a string or binary value.

Secret Rotation

Secret rotation is the process of updating a secret by storing a new version. It enhances security by leveraging the multi-version capability of secrets. The new secret version is marked as SYSCURRENT. Applications will dynamically read the secret value corresponding to SYSCURRENT.

Rotation Process

Rotation Types

  • Periodic automatic rotation: You can configure a rotation period. The system will automatically rotate secrets when they expire. In CSMS, you can configure a rotation period for a rotated secret, but not for a shared secret. To periodically rotate a shared secret, you can develop a custom function.
  • Immediate rotation: If your secret is leaked, you can rotate it immediately. Rotated secrets support immediate rotation. For a shared secret, you can only rotate it by manually storing a secret value.

Rotation Policies

When you create a secret, select a rotation policy based on the secret value.

  • If Secret Value is set to Single account, the single-user rotation policy is used.
  • If it is set to Dual account, the dual-user rotation policy is used.
Table 2 Rotation policies

Rotation Policy

Description

Single-user rotation

The single-user rotation policy is mainly used for accounts with low rotation frequency and low reliability requirements. This is a simple rotation policy suitable for most cases. Note that the current secret may be temporarily unavailable at the moment when the password is reset.

If you choose single-user rotation, you can:

  • Select or create a database account to store a secret value when creating a secret.
  • Access databases. Database connection will not be deleted during secret rotation. After the rotation, new connections will use the new secret.

Dual-user rotation

Dual-user rotation is mainly used for accounts with high rotation frequency and high reliability requirements. Two accounts with the same permission are hosted. The secret of the SYSPREVIOUS status is rotated each time. Access will not be interrupted when a password is reset. During the rotation, the status of the new secret is changed to SYSPENDING, and the RDS API is called to reset the password. After the reset, the status of the new secret is changed from SYSPENDING to SYSCURRENT, and the status of the secret in the SYSCURRENT state is changed to SYSPREVIOUS.

  • You need to select or create two database accounts to store secret values.
  • The two secret values are rotated alternately. You need to obtain the secret value of SYSCURRENT each time.

Using Rotated Secrets

Figure 1 Architecture

Step 1: Create an Agency for Secret Rotation

When the rotation function is enabled for the first time, CSMS automatically creates an agency for the user in the current project of the region after the user confirms the authorization. Therefore, users need to ensure that the account has the following IAM permissions: iam:permissions:grantRoleToAgencyOnProject, iam:agencies:listAgencies, iam:roles:listRoles, iam:agencies:createAgency, iam:permissions:checkRoleForAgencyOnProject, and iam:roles:createRole.

The agency to be created varies depending on the type of the secret to be rotated.

  • RDS secret
    • Create an agency named CSMSAccessFunctionGraph with account named op_svc_kms and permission named CSMSAccessFunctionGraph. The agency uses a project-level service policy, which includes the functiongraph:function:invoke permission for FunctionGraph.
    • Create an agency named FunctionGraphAgencyForRotateRDSByCSMSV3. The cloud service is FunctionGraph, and the permission name is FunctionGraphAgencyForRotateRDSByCSMSV3. The project-level service policy is used, including:
      • CSMS permissions: csms:secret:getVersion, csms:secret:listVersion, csms:secret:createVersion, csms:secret:getStage, csms:secret:get, and csms:secret:updateStage
      • VPC permissions: vpc:ports:create, vpc:vpcs:get, vpc:ports:get, vpc:ports:delete, and vpc:subnets:get
      • KMS permissions: kms:cmk:createDataKey and kms:cmk:decryptDataKey
      • RDS permission: rds:password:update
  • TaurusDB secret
    • Create an agency named CSMSAccessFunctionGraph with account named op_svc_kms and permission named CSMSAccessFunctionGraph. The agency uses a project-level service policy, which includes the functiongraph:function:invoke permission for FunctionGraph.
    • Create an agency named FunctionGraphAgencyForRotateGaussDBByCSMSV3. The cloud service is FunctionGraph, and the permission name is FunctionGraphAgencyForRotateGaussDBByCSMSV3. The project-level service policy is used, including:
      • CSMS permissions: csms:secretVersion:get, csms:secretVersion:list, csms:secretVersion:create, csms:secretStage:get, csms:secret:get, and csms:secretStage:update
      • VPC permissions: vpc:ports:create, vpc:vpcs:get, vpc:ports:get, vpc:ports:delete, and vpc:subnets:get
      • KMS permissions: kms:dek:create and kms:dek:decrypt
      • TaurusDB permission: gaussdb:user:modify
  • APIG secret
    • Create an agency named CSMSAccessFunctionGraph with account named op_svc_kms and permission named CSMSAccessFunctionGraph. The agency uses a project-level service policy, which includes the functiongraph:function:invoke permission for FunctionGraph.
    • Create an agency named FunctionGraphAgencyForRotateGaussDBByCSMSV3. The cloud service is FunctionGraph, and the permission name is FunctionGraphAgencyForRotateGaussDBByCSMSV3. The project-level service policy is used, including:
      • CSMS permissions: csms:secretVersion:get, csms:secretVersion:list, csms:secretVersion:create, csms:secretStage:get, csms:secret:get, and csms:secretStage:update
      • VPC permissions: vpc:ports:create, vpc:vpcs:get, vpc:ports:get, vpc:ports:delete, and vpc:subnets:get
      • KMS permissions: kms:dek:create and kms:dek:decrypt
      • APIG permissions: apig:apps:update, apig:instances:get, apig:apps:get, apig:appCodes:create, apig:appCodes:get, and apig:appCodes:delete
  • GaussDB secret
    • Create an agency named CSMSAccessFunctionGraph with account named op_svc_kms and permission named CSMSAccessFunctionGraph. The agency uses a project-level service policy, which includes the functiongraph:function:invoke permission for FunctionGraph.
    • Create an agency named FunctionGraphAgencyForRotateGaussDBByCSMSV3. The cloud service is FunctionGraph, and the permission name is FunctionGraphAgencyForRotateGaussDBByCSMSV3. The project-level service policy is used, including:
      • CSMS permissions: csms:secretVersion:get, csms:secretVersion:list, csms:secretVersion:create, csms:secretStage:get, csms:secret:get, and csms:secretStage:update
      • VPC permissions: vpc:ports:create, vpc:vpcs:get, vpc:ports:get, vpc:ports:delete, and vpc:subnets:get
      • KMS permissions: kms:dek:create and kms:dek:decrypt
      • GaussDB permission: gaussdb:instance:modify

Step 2: Create a Rotated Secret

  • Set the secret name and tag.
  • Configure an automatic rotation policy.

For details, see Creating a Rotated Secret.

Step 3: Obtain the Secret Value and Enable Periodic Rotation

  1. An application system can request an access secret from CSMS and obtain the secret value to access the corresponding database. For details about how to call APIs, see Querying the Secret Version and Value.
  2. The application system uses the returned secret value to parse the plaintext data. After obtaining the account and password, the application system can access the target database corresponding to the user.
  3. Enable periodic secret rotation.
    After automatic rotation is enabled, the passwords hosted by the database instance will be updated periodically. Ensure that the application that uses the database instance has completed code adaptation so that the latest secrets can be dynamically obtained when the database connection is established.

    Do not cache any information in secrets. Otherwise, the account and password may become invalid after rotation, causing database connection failures.

References

Parent Topic: CSMS