Key Management Service:How KMS works with RAM

RAM features supported by KMS

The following table describes the RAM features and whether the features are supported by KMS.

RAM user-based access

KMS supports RAM user-based access.

A RAM user is a physical identity that has a fixed ID and credential information. A RAM user represents a person or an application. If a RAM user uses an identity credential to access KMS, KMS verifies the permissions of the RAM user on resources.

• Identity credentials are configured when you create the RAM user. You can create a RAM user only by using the administrator account. If you use a RAM user to access cloud resources by using the console of the service, you must provide the username and password of the RAM user. If you use a RAM user to access cloud resources by calling API operations, you must provide the Access Key pair of the RAM user. We recommend that you change the password of a RAM user on a regular basis and do not embed the plaintext Access Key pair of a RAM user in code. This improves the security of RAM identity credentials. For more information, see Identity management.

  Note

  An administrator account is an Alibaba Cloud account, or a RAM user or a RAM role that has administrative rights.

• By default, a RAM user does not have any permissions. After you create a RAM user, you must use the administrator account to attach the RAM user the required policies to access or manage cloud resources. Identity-based policies include system policies and custom policies. For more information, see system policies for KMS and custom policies for KMS. System policies are created by Alibaba Cloud. You can create custom policies.

References

• Create a RAM user

• Create an AccessKey pair

• Grant permissions to a RAM user

STS token-based access

KMS supports STS token-based access.

An STS token is an identity credential that is used by a RAM role to access cloud resources. STS, which is provided by RAM, issues STS tokens for trusted entities to assume RAM roles. A RAM role is a virtual RAM identity. A RAM role does not have long-term identity credentials and must be assumed by a trusted entity.

Compared with long-term credentials such as AccessKey pairs, you can use temporary identity credentials such as STS tokens to reduce the exposure duration and improve the security of your cloud assets. For more information about the trusted entities and the typical scenarios in which RAM roles and STS tokens are used, see RAM role overview.

By default, a RAM role does not have any permissions. You must use the administrator account to attach the required policies to the RAM role to access or perform operations on cloud resources. Identity-based policies include system policies and custom policies. For more information, see system policies for KMS and custom policies for KMS. System policies are created by Alibaba Cloud. You can create custom policies.

References

• Create a RAM role

  • Create a RAM role for a trusted Alibaba Cloud account

  • Create a RAM role for a trusted Alibaba Cloud service

  • Create a RAM role for a trusted IdP

• Grant permissions to a RAM role

• Assume a RAM role

Identity-based policies

KMS supports identity-based policies.

You can attach identity-based policies to RAM identities, such as RAM users, RAM user groups, or RAM roles. The identity-based policies define what operations the preceding RAM identities can perform on which resources and under what conditions.

• From the management perspective, identity-based policies include system policies and custom policies System policies are created and maintained by Alibaba Cloud. You can only use system policies. You cannot modify or delete system policies. You can create and maintain custom policies. You can create custom policies in the RAM console or by calling API operations.

• From the perspective of authorization scope, identity-based policies include account-level policies and resource group-level policies. The authorization scope of account-level policies is all resources within an Alibaba Cloud account. The authorization scope of resource group-level policies is all resources in a resource group. Account-level policies take precedence over resource group-level policies. For more information about the definitions and authorization scopes, see Policy models. You can specify the authorization scope when you grant permissions to a RAM identity.

References

• System policies for KMS

• Custom policies for KMS

• Create custom policies

Operation-level authorization

KMS supports operation-level authorization.

In a policy, the Action element specifies the operations that an identity can or cannot perform. In most cases, the value of the Action element is the same as the name of the API operation of the related Alibaba Cloud service. The Action element is in the <ram-code>:<action-name> format.

KMS supports the operation-level authorization granularity. You can configure access permissions for a specific operation in a policy.

• The code (ram-code) in RAM that is used to indicate KMS is kms.

• For a list of all operations that are supported by KMS, see Custom policies for KMS.

Example of the Action element in a policy of KMS

      "Action": [
        "kms:List*",
        "kms:Describe*"
      ]

Resource-level authorization

KMS supports resource-level authorization.

KMS supports resource-level authorization. You can configure access permissions for a specific resource object in a policy. For more information about all resources that are supported by KMS, see Custom policies for KMS.

Example of the Resource element in a policy of KMS

 "Resource": [
        "acs:kms:${region}:${account}:key",
        "acs:kms:${region}:${account}:key/*"
      ]

Condition keys specific to Alibaba Cloud services

KMS supports condition keys specific to Alibaba Cloud services.

KMS supports condition keys specific to Alibaba Cloud services. You can configure conditions that are required for a policy to take effect when you configure permissions for specific operations and resource objects. For more information about condition keys specific to Alibaba Cloud services that are supported by KMS, see the Custom policies for KMS.

Example of the Condition element in a policy of KMS

            "Condition": {
                "StringEqualsIgnoreCase": {
                    "kms:tag/Project": [
                        "Apollo"
                    ]
                }
            }

Tag-based authentication

KMS supports tag-based authentication.

Regular service roles

KMS supports regular service roles.

Regular service roles are RAM roles that are assumed by trusted Alibaba Cloud services. Regular service roles are used for access between Alibaba Cloud services. When you use a specific feature of KMS, user authorization is triggered to automatically create a regular service role and grant the required resource access permissions to the regular service role. After the regular service role is created, KMS can assume the regular service role to access other cloud services.

You can also manually create, modify, and delete regular service roles in RAM, and modify the policies that are attached to regular service roles. If you modify a regular service role or the policies that are attached to a regular service role, the features that are provided by KMS are affected. Proceed with caution. For more information, see Regular service roles.

Service-linked roles

KMS supports service-linked roles.

Service-linked roles are RAM roles that are assumed by trusted Alibaba Cloud services. Service-linked roles are used to access Alibaba Cloud services across Alibaba Cloud services. When you use a specific feature of KMS, user authorization is triggered to automatically create a service-linked role and grant the required resource access permissions to the service-linked role. After the service-linked role is created, KMS can assume the service-linked role to access other cloud services.

The service-linked roles of KMS are RAM roles that only KMS can assume. The policies that are attached to the service-linked role are defined, updated, and used by KMS. You can view the policies that are attached to the service-linked roles in RAM. You cannot modify or delete the policies, or attach policies to or detach policies from the service-linked roles. For more information, see Service-linked roles.