All Products
Search

This Product

    Key Management Service:Manage and use ApsaraDB for Redis/Tair secrets

    Document Center

    Key Management Service:Manage and use ApsaraDB for Redis/Tair secrets

    Last Updated:Aug 20, 2024

    You can manage the account of an ApsaraDB for Redis database or an ApsaraDB for Redis Enhanced Edition (Tair) database in an ApsaraDB for Redis/Tair secret of Key Management Service (KMS). In this case, if you integrate an SDK into your application, your application can dynamically retrieve the secret from KMS to log on to the database. You can configure secret rotation to reduce the risks of account leaks. This topic describes how to manage and use an ApsaraDB for Redis/Tair secret.

    Feature description

    If you use an ApsaraDB for Redis/Tair secret, you do not need to configure static database accounts in applications. After you create an ApsaraDB for Redis/Tair secret for a database in KMS, applications can call the GetSecretValue operation to retrieve the secret to access the database.

    You can manage new ApsaraDB for Redis or Tair accounts in ApsaraDB for Redis/Tair secrets only in dual-account mode. You cannot manage existing accounts. When you create an ApsaraDB for Redis/Tair secret in KMS, you must configure custom database accounts. In this case, KMS calls an operation of ApsaraDB for Redis or Tair to create two accounts that have the same permissions and passwords. Take an ApsaraDB for Redis database as an example. If you enter the user username prefix, the accounts named user and user_clone are created. The version stage label for the secret of the user account is set to ACSCurrent, and the version stage label for the secret of the user_clone account is set to ACSPrevious. To view the ApsaraDB for Redis accounts, log on to the ApsaraDB for Redis console, go to the Instances page, and then find the associated instance. On the details page of the instance, click Account Management.

    If you configure secret rotation, the passwords of the two ApsaraDB for Redis accounts are valid during secret rotation. In this case, when the secret is being rotated, applications can still retrieve a valid secret. Compared with the single-account mode, the dual-account mode ensures higher availability for your applications.

    Important

    If you manage ApsaraDB for Redis or Tair accounts in KMS, do not modify or delete the accounts in ApsaraDB for Redis or Tair. Otherwise, service failures may occur.

    The following process uses an ApsaraDB for Redis database as an example to describe how to use a secret.

    image

    Prerequisites

    Create an ApsaraDB for Redis/Tair secret

    When you create a secret, you can configure automatic rotation for the secret. This helps reduce the risk of secret leaks.

    1. Log on to the KMS console. In the top navigation bar, select a region. In the left-side navigation pane, choose Resource > Secrets.

    2. Click the Database Secrets tab, select the ID of the KMS instance from the Instance ID drop-down list, and then click Create Secret.

    3. Select Create Single Secret or Create Bulk Secrets. Then, configure the parameters and click OK.

      Note

      When you create a secret, the system automatically creates the AliyunServiceRoleForKMSSecretsManagerForRedis service-linked role and attaches the AliyunServiceRolePolicyForKMSSecretsManagerForRedis policy to the role. KMS assumes the role to manage the secret. For example, KMS can rotate the passwords of the accounts that are stored in the secret.

      You can log on to the RAM console to view the details of service-linked roles and policies. For more information, see View the information about a RAM role and View the basic information about a policy.

      In the following example, a single secret is created.

      Parameter

      Description

      Database Type

      The type of the database secret. Select ApsaraDB for Redis/Tair Secrets.

      Secret Name

      The name of the secret.

      ApsaraDB for Redis/Tair Secrets

      The ApsaraDB for Redis or Tair instance that you want to manage. Select an existing instance within your Alibaba Cloud account.

      Account Management

      Only Manage Dual Accounts is supported.

      Secret Value

      You can manage new accounts in secrets only in dual-account mode. You cannot manage existing accounts in KMS.

      • Account Name: Enter a username prefix. Then, KMS calls an operation of ApsaraDB for Redis or Tair to create two accounts that have the same permissions and passwords. Take an ApsaraDB for Redis database as an example. If you enter the user username prefix, accounts named user and user _clone are created.

      • Permissions: Valid values are Read/Write and Read-Only. The two accounts have the same permissions.

      CMK

      The key that is used to encrypt the secret.

      Important

      • Your 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.

      • If you are a RAM user or a RAM role, you must have the permissions to call the GenerateDataKey operation by using a key.

      Tag

      The tag that you want to add to the secret. You can use tags to classify and manage secrets. A tag consists of a key-value pair.

      Note

      • A tag key or a tag value can be up to 128 characters in length and can contain letters, digits, forward slashes (/), backslashes (\), underscores (_), hyphens (-), periods (.), plus signs (+), equal sign (=), colons (:), at signs (@), and spaces.

      • A tag key cannot start with aliyun or acs:.

      • You can configure up to 20 key-value pairs for each secret.

      Automatic Rotation

      Specifies whether to enable automatic secret rotation.

      Rotation Period

      The interval of automatic secret rotation. This setting is required only when you enable Automatic Rotation. The value ranges from 6 hours to 365 days.

      KMS periodically updates the secret based on the value of the parameter.

      Description

      The description of the secret.

      Policy Settings

      The policy settings of the secret. For more information about policies, see Overview.

      • Default Policy: If the secret is used by the current Alibaba Cloud account or the Alibaba Cloud account in a resource share, select Default Policy.

        • If the KMS instance is not shared with other accounts, only the current Alibaba Cloud account can manage and use the secret.

        • If the KMS instance is shared with other accounts, the supported operations vary. For example, an instance named KMS Instance A is shared with Alibaba Cloud Account 2 by using Alibaba Cloud Account 1.

          • Secrets created by Alibaba Cloud Account 1: Only Alibaba Cloud Account 1 can manage and use the secrets.

          • Secrets created by Alibaba Cloud Account 2: Both Alibaba Cloud Account 1 and Alibaba Cloud Account 2 can manage and use the secrets.

      • Custom Policy: If you want to grant permissions to a RAM user, RAM role, or other accounts to use the secret, select Custom Policy.

        Important

        • Administrators and users do not consume Access Management Quota. Cross-account users consume the Access Management Quota of the KMS instance. The consumed quota is calculated based on the number of Alibaba Cloud accounts. If you revoke the permissions, wait for approximately 5 minutes and then query the quota. The consumed quota is restored.

        • When you use a secret, you must have the permissions to use the required key to decrypt the secret.

        • An administrator can manage the secret but cannot retrieve the secret value. You can select RAM users and RAM roles within the current Alibaba Cloud account.

          Permissions supported by administrators

          {
	"Statement": [
		{
			"Action": [
				"kms:List*",
				"kms:Describe*",
				"kms:PutSecretValue",
				"kms:Update*",
				"kms:DeleteSecret",
				"kms:RestoreSecret",
				"kms:RotateSecret",
				"kms:TagResource",    
				"kms:UntagResource" 
			]
		}
	]
}

        • A user can retrieve the secret value. You can select RAM users and RAM roles within the current Alibaba Cloud account.

          Permissions supported by users

          {
    "Statement": [
        {
            "Action": [
                "kms:List*",
		"kms:Describe*",
		"kms:GetSecretValue",
            ]
        }
    ]
}

        • A cross-account user can retrieve the secret value. A cross-account user can be a RAM user or a RAM role of other Alibaba Cloud accounts.

          • RAM user: The name of the RAM user is in the acs:ram::<userId>:user/<ramuser> format. Example: acs:ram::119285303511****:user/testpolicyuser.

          • RAM role: The name of a RAM role is in the acs:ram::<userId>:role/<ramrole> format. Example: acs:ram::119285303511****:role/testpolicyrole.

          Note

          After you grant permissions to a RAM user or a RAM role, you must use the Alibaba Cloud account of the RAM user or the RAM role to grant the RAM user or the RAM role permissions to use the secret in RAM. Then, the RAM user or the RAM role can use the secret.

          For more information, see Use RAM to manage access to KMS resources, Grant permissions to a RAM user, and Grant permissions to a RAM role.

          Permissions supported by cross-account users

          {
    "Statement": [
        {
            "Action": [
                "kms:List*",
		"kms:Describe*",
		"kms:GetSecretValue",
            ]
        }
    ]
}

    Integrate ApsaraDB for Redis/Tair secrets into applications

    KMS provides Alibaba Cloud SDK, KMS Instance SDK, and the secret client to retrieve secrets. Applications can use the SDKs to integrate ApsaraDB for Redis/Tair secrets. For more information about SDKs, see SDK references.

    Note

    • For more information about how to use KMS Instance SDK, see Use KMS to manage ApsaraDB for Redis secrets.

    • If you use SDKs to perform management operations, such as creating ApsaraDB for Redis/Tair secrets and modifying tags that are added to the secrets, you can use only Alibaba Cloud SDK.

    Rotate an ApsaraDB for Redis/Tair secret

    When KMS rotates an ApsaraDB for Redis/Tair secret, the password of the associated account is changed. The username of the account remains unchanged. If the rotation is not complete after more than 2 minutes, check whether the associated ApsaraDB for Redis or Tair instance and the associated ApsaraDB for Redis or Tair account are normal.

    Usage notes before rotation

    • When an ApsaraDB for Redis/Tair secret is being rotated, KMS sends a request to ApsaraDB for Redis or Tair to change the password of the associated account. Before you rotate a secret, make sure that all your applications retrieve the secret from KMS. This helps prevent application unavailability.

    • When a secret is being rotated, do not delete the instance and account that are associated with the secret. Otherwise, rotation failures occur.

    • We recommend that you perform an account check before the rotation and perform the rotation after KMS prompts that the check is successful. If you delete the instance or account in ApsaraDB for Redis or Tair that is associated with a secret, KMS cannot rotate the secret.

    Rotation process

    You can use only the dual-account mode to manage ApsaraDB for Redis/Tair secrets. When you create an ApsaraDB for Redis/Tair secret in KMS, you must configure custom ApsaraDB for Redis or Tair accounts. In this case, KMS calls an operation of ApsaraDB for Redis or Tair to create two accounts that have the same permissions and passwords.

    Take an ApsaraDB for Redis database as an example. If you enter the user username prefix, the accounts named user and user_clone are created. The version stage label for the secret of the user account is set to ACSCurrent, and the version stage label for the secret of the user_clone account is set to ACSPrevious.

    During the first rotation, KMS calls an ApsaraDB for Redis operation to change the password of the user account, and sets the version stage label for the secret of the user account to ACSPrevious and the version stage label for the secret of the user_clone account to ACSCurrent. KMS alternately changes the passwords of the two accounts each time the secret is rotated. The following figure shows the details.

    image

    You can configure automatic rotation for a secret to reduce the risk of secret leaks. If a secret is leaked, you can immediately rotate the secret in the KMS console to eliminate intrusion risks.

    1. Log on to the KMS console. In the top navigation bar, select a region. In the left-side navigation pane, choose Resource > Secrets.

    2. Click the Database Secrets tab, select the ID of the KMS instance from the Instance ID drop-down list, select Redis/Tair from the Secret Type drop-down list, find the secret that you want to rotate, and then click Details in the Actions column.

    3. In the Versions tab, click Configure Rotation to configure a rotation policy.

      • Automatic Rotation: If you turn on Automatic Rotation, you must select a rotation period. The value ranges from 6 hours to 365 days.

      • Rotation Now: If you select this option, KMS immediately rotates the secret.

    What to do next

    Perform an account check

    KMS checks whether an account that is protected by a secret belongs to the associated ApsaraDB for Redis instance or Tair instance. If yes, the secret can be rotated. If no, you must delete the secret and create another ApsaraDB for Redis/Tair secret.

    1. Log on to the KMS console. In the top navigation bar, select a region. In the left-side navigation pane, choose Resource > Secrets.

    2. Click the Database Secrets tab, select the ID of the KMS instance from the Instance ID drop-down list, select Redis/Tair from the Secret Type drop-down list, find the secret that you want to rotate, and then click Details in the Actions column.

    3. In the Versions tab, click Check Account. After the check is complete, view the check result.

    Delete an ApsaraDB for Redis/Tair secret

    Warning

    Before you delete an ApsaraDB for Redis/Tair secret, make sure that the secret is no longer in use. If you delete a secret that is in use, service failures may occur.

    You can immediately delete a secret or create a scheduled task to delete a secret. If you delete an ApsaraDB for Redis/Tair secret, the secret is deleted only from KMS. The username and password in the secret are not deleted in ApsaraDB for Redis or Tair.

    1. Log on to the KMS console. In the top navigation bar, select a region. In the left-side navigation pane, choose Resource > Secrets.

    2. Click the Database Secrets tab, select the ID of the KMS instance from the Instance ID drop-down list, select Redis/Tair from the Secret Type drop-down list, find the secret that you want to delete, and then click Schedule Deletion in the Actions column.

    3. In the Schedule Deletion dialog box, select a method to delete the secret and click OK.

      • If you select Schedule Deletion, configure Retention Period (7 to 30 Days). When the scheduled deletion period ends, KMS deletes the secret.

      • If you select Delete Immediately, the system immediately deletes the secret.

      During the scheduled deletion period, you can click Restore Secret in the Actions column to cancel the deletion.

    Add tags to secrets

    You can use tags to classify and manage secrets. A tag consists of a key-value pair.

    Note

    • A tag key or a tag value can be up to 128 characters in length and can contain letters, digits, forward slashes (/), backslashes (\), underscores (_), hyphens (-), periods (.), plus signs (+), equal sign (=), colons (:), at signs (@), and spaces.

    • A tag key cannot start with aliyun or acs:.

    • You can configure up to 20 key-value pairs for each secret.

    Add tags for a secret

    Solution

    Description

    Method 1: Add tags on the Secrets page

    1. Log on to the KMS console. In the top navigation bar, select a region. In the left-side navigation pane, choose Resource > Secrets.

    2. Click a tab based on the type of your secret, select the required instance ID from the Instance ID drop-down list, find the desired secret, and then click the image.png icon in the Tag column.

    3. Click Add. In the Edit Tag dialog box, enter multiple Tag Key and Tag Value, and click OK. In the message that appears, click Close.

      In the Edit Tag dialog box, you can modify the tag values and remove multiple tags at a time.

    Method 2: Add tags on the Secret Details page

    1. Log on to the KMS console. In the top navigation bar, select a region. In the left-side navigation pane, choose Resource > Secrets.

    2. Click a tab based on the type of your secret. Select the required instance ID from the Instance ID drop-down list, find the desired secret, and then click Details in the Actions column.

    3. On the Secret Details page, click the image.png icon next to Tag.

    4. In the Edit Tag dialog box, enter multiple Tag Key and Tag Value and click OK. In the message that appears, click Close.

      In the Edit Tag dialog box, you can modify the tag values and remove multiple tags at a time.

    Configure tags for multiple secrets at a time

    1. Log on to the KMS console. In the top navigation bar, select a region. In the left-side navigation pane, choose Resource > Secrets.

    2. Click a tab based on the type of your secret, select the required instance ID from the Instance ID drop-down list, and then select the desired secrets from the secret list.

      • Add tags: In the lower part of the secret list, click Add Tag. In the Add Tag dialog box, enter multiple Tag Key and Tag Value, and click OK. In the message that appears, click Close.

      • Remove tags: In the lower part of the secret list, click Remove Tag. In the Batch Remove dialog box, select the tags that you want to remove and click Remove. In the message that appears, click Close.

    FAQ