Introduction to RAM and STS

Background

RAM and STS address a core challenge: how to securely grant access to other users without exposing the AccessKey of an Alibaba Cloud account. If the AccessKey of an Alibaba Cloud account is exposed, it creates a major security risk. Anyone who obtains the AccessKey can manage all resources under the account and steal important information.

RAM provides a long-term access control mechanism. You can create RAM users and grant them specific permissions. The AccessKeys of RAM users must also be kept confidential. Even if a RAM user's AccessKey is exposed, the security risk is limited and does not compromise all resources under the account. RAM users are typically valid for a long time.

In contrast to the long-term control mechanism of RAM, STS provides temporary access authorization. You can call STS to obtain a temporary AccessKey and token. You can then send the temporary AccessKey and token to temporary users to allow them to access resources. Permissions obtained from STS are more strictly limited and have a time limit. Therefore, if the credentials are exposed, the impact is relatively small.

For an example scenario, see Usage example.

Terms

For more information about the basic concepts of RAM and STS, see RAM-related concepts.

RAM users and roles are similar to a person and their different identities. For example, a person can be an employee at work and a parent at home. The same person plays different roles in different scenarios, and each role has its own set of permissions. A role itself is not an active entity. It can be used to perform operations only when a user assumes the role. A role can also be assumed by multiple users at the same time.

Usage example

To prevent the security risks that arise from an exposed AccessKey, an Alibaba Cloud account administrator can use RAM to create two RAM users: A and B. The administrator generates independent AccessKeys for A and B. User A is granted read permissions, and User B is granted write permissions. The administrator can cancel the permissions of the RAM users in the Resource Access Management (RAM) console at any time.

If another person needs temporary permission to access IoT Platform APIs, you should not directly expose User A's AccessKey. Instead, you can create a new role, C, and grant it permission to read IoT Platform APIs. Role C cannot be used directly because it does not have a corresponding AccessKey. It is a virtual entity that holds the permissions required to access IoT Platform APIs.

You can call the STS AssumeRole API operation to obtain temporary authorization to access the IoT Platform APIs. In the request to STS, set the RoleArn parameter to the ARN of Role C. If the call is successful, STS returns a temporary AccessKeyId, AccessKeySecret, and SecurityToken. These items serve as the access credential. The expiration time of the credential is specified in the AssumeRole request. You can send this credential to the user who needs access. The user then has temporary permission to access the IoT Platform APIs.

Why are RAM and STS complex?

The concepts and usage of RAM and STS are complex. This complexity is a trade-off for greater account security and flexible permission control.

Separating RAM users and roles distinguishes between the entity that performs operations and the virtual entity that represents a collection of permissions. If a user needs multiple permissions, such as read and write, but each operation requires only a subset of those permissions, you can create two roles. One role has read permissions, and the other has write permissions. Then, you can create a RAM user that can assume both roles. When the user needs to read data, they can assume the role with read permissions. The same applies when they need to write data. This approach reduces the risk of permission leaks during each operation. In addition, this role-based approach lets you grant permissions to other users, which simplifies collaboration.

STS provides more flexible control over permissions. For example, you can set the validity period as needed. However, if you need a long-term access credential, you can use the RAM user management feature without using STS.

The following sections provide guides and examples for using RAM and STS. For more information about the code details for RAM and STS, see RAM API and STS API.