RAM and STS are permission management systems provided by Alibaba Cloud.
RAM is primarily used to control account system permissions. RAM enables users to create subaccounts within the range of primary account permissions. Different subaccounts can be allocated different permissions for authorization management.
STS is a security credential (token) management system that grants temporary access permissions. STS allows users to grant access rights to temporary accounts.
RAM and STS are designed to solve the core issue: how to securely grant access permissions to others without disclosing the primary account’s AccessKey. AccessKey disclosure poses serious security risks because unauthorized users may operate account resources and steal important information.
What RAM actually provides is a long-term permission control mechanism. Different subaccounts assign different permissions to different users. This way, even the disclosure of subaccount information would not cause a global information leakage. However, subaccounts have long-term validity. Therefore, AccessKey of subaccounts must not be disclosed.**
As opposed to RAM’s long-term control mechanism, STS provides temporary access authorization by returning a temporary AccessKey and token. This information can be provided directly to temporary accounts, allowing them access to the OSS. Generally, the permissions obtained from STS are more restrictive and only valid for a limited period of time. Thus, the disclosure of this information has little effect on the system.
In later sections, we use real examples to illustrate these functions.
Below, we provide simple explanations of some basic concept:
- Subaccount: A subaccount is created from an Alibaba Cloud primary accounts. Once created, it is assigned an independent password and permissions. Each subaccount has its own AccessKey and can perform authorized operations in the same way as the primary account. Generally, subaccounts can be understood as users with certain permissions or operators with permissions for specified operations.
- Role: Roles are a virtual concept for certain operation permissions, but they do not have independent logon passwords or AccessKeys. Subaccounts can assume roles and the permissions granted when a role is assumed are the permissions of this role.
- Policy: Policies are rules used to define permissions; for example, they permit users to read or write certain resources.
- Resource: Resources are the cloud resources that users can access like all OSS buckets, a certain OSS bucket, or a certain object in a specific OSS bucket.
A subaccount and roles have the same relationship to each other as you and your identities. At work, you may be an employee, while at home you may be a father. In different scenarios, you may assume different roles. Different roles are assigned corresponding permissions. The concept of “employee” or “father” is not an actual entity that can be the subject of actions. These concepts are only complete when an individual assumes them. This illustrates an important concept: a role may be assumed by multiple people at the same time. After a role is assumed, this individual automatically obtains all the permissions of the role.
One more example is given for further clarification.
Assume that an Alibaba Cloud user named Alice has two private OSS buckets, alice_a and alice_b. Alice has full permission for both buckets.
In order to avoid leaking her Alibaba Cloud account AccessKey, which would pose a major security risk, Alice uses RAM to create two subaccounts, Bob and Carol. Bob has read/write permission for alice_a and Carol has read/write permission for alice_b. Bob and Carol both have their own AccessKeys. This way, if one is leaked, only the corresponding bucket will be affected and Alice can easily cancel the leaked user permissions on the console.
Now, for some reason, Alice must authorize another person to read the objects in alice_a. In this situation, she should not simply disclose Bob’s AccessKey. Rather, she can create a new role like AliceAReader, and grant this role the read permission for alice_a. However, please note that, at this time, AliceAReader cannot be used because no AccessKey corresponds to this role. AliceAReader is currently only a virtual entity with the permission to access alice_a.
In order to obtain temporary authorization, Alice can call the STS’s AssumeRole interface to tell the STS that Bob wants to assume the AliceAReader role. If successful, the STS will return a temporary AccessKeyId, AccessKeySecret, SecurityToken, which serve as the access credentials. When these credentials are given to a temporary account, the user obtains temporary permission to access alice_a. The credentials’ expiration time is specified when the AssumeRole interface is called.
At first glance, the RAM and STS concepts seem very complex. This is because flexibility is given to permission control at the cost of simplicity.
Subaccounts and roles are separated to separate the entity that executes operations from the virtual entity that represents a permissions set. If a user requires many permissions including the read and write permissions but each operation only requires part of the total permission set, you can create two roles, one with the read permission and the other with the write permission. Then create a user that does not have any permissions but can assume these two roles. When the user needs to read or write data, the user can temporarily assume the role with the read permission or the role with the write permission. This reduces the risk of permission leaks for each operation. In addition, roles can be used to grant permissions to other Alibaba Cloud users, making collaboration easier.
Of course, the flexibility does not mean you have to use all these functions. You should only use the subset of functions as needed. For example, if you do not need to use temporary access credentials that have an expiration time, you can simply use the RAM subaccount function, without STS.
In what follows, we will use examples to create a RAM and STS user guide and provide instructions. For the operations in these examples, we do our best to use console and command line operations to reduce the actual amount of codes that must be used. If you must use code to perform these operations, we recommend that you refer to the RAM and STS API Manual.
During testing, we use osscmd, a tool in the OSS PythonSDK that allows you to directly work on OSS through the command line. The address obtained is Python SDK.
Typical osscmd usage:
./osscmd get oss://BUCKET/OBJECT LOCALFILE --host=Endpoint -i AccessKeyId -k AccessKeySecret
Here, replace BUCKET and OBJECT with your own bucket and object, and the endpoint format should be similar to oss-cn-hangzhou.aliyuncs.com. For AccessKeyId and AccessKeySecret, use the information corresponding to your own account
./osscmd put LOCALFILE oss://BUCKET/OBJECT --host=Endpoint -i AccessKeyId -k AccessKeySecret
The meaning of each field is the same as for the download example