Avoid using your Alibaba Cloud account directly to access Compute Nest. Instead, use Resource Access Management (RAM) users or RAM roles.
Choose an identity type
| Identity type | Best for | Credentials |
|---|---|---|
| RAM role | Applications and services | Temporary STS token (recommended) |
| RAM user | Individual team members who need console access | Logon password or permanent AccessKey |
| RAM user group | Managing permissions for multiple team members at scale | Inherited from the group |
RAM roles
A RAM role is a virtual identity with policies attached. Unlike RAM users, RAM roles have no permanent credentials — no logon password and no AccessKey pair. A trusted entity assumes the role to get a short-lived Security Token Service (STS) token, then uses that token to access Alibaba Cloud resources.
This design limits exposure: if an STS token is compromised, it expires automatically. A leaked AccessKey pair, by contrast, stays valid until you manually revoke it.
How it works
Grant a trusted entity permission to assume the RAM role.
The trusted entity calls the AssumeRole operation to get an STS token.
The trusted entity uses the STS token to access resources as the RAM role.
The token expires at the end of the session duration.
Security practices
Minimize trusted entity changes. Changing the trusted entity of an existing RAM role risks permission loss or unintended privilege escalation — either outcome can disrupt your services or open security gaps. Test all changes thoroughly before applying them.
Set an appropriate session duration. The STS token's maximum validity equals the maximum session duration configured for the RAM role. A shorter session duration reduces the window of exposure if a token is compromised. Set it to the minimum your use case requires.
Enable single sign-on (SSO) for RAM roles if your organization uses an enterprise identity system. This lets team members access Alibaba Cloud without maintaining separate credentials.
Related topics
RAM users
Use RAM users for individuals who need to log on to the Alibaba Cloud Management Console or call APIs directly. RAM users have permanent credentials tied to a person or program.
When you create a RAM user, set the Access Mode parameter:
| Access mode | How they authenticate | Intended for |
|---|---|---|
| Console Access | Username and logon password | Individual team members |
| Using permanent AccessKey to access | AccessKey ID and AccessKey secret | Programmatic access |
| Both | Either method | (Use sparingly) |
Security practices
Create a dedicated admin RAM user first. Use your Alibaba Cloud account to create one RAM user with administrative rights, then use that RAM user — not the root account — to create and manage all other RAM users. Using the root account for day-to-day operations increases the blast radius of any account compromise.
Separate human users from program users. A person's account should not be used by automation, and vice versa. Mixing them obscures audit trails and risks an automated script running with a human's broader permissions.
Enable multi-factor authentication (MFA) for console users. Without MFA, a stolen password alone is enough to compromise the account. MFA blocks the vast majority of credential-based attacks.
Apply least-privilege permissions. Grant each RAM user only the permissions their role requires. Overly broad permissions increase the damage from any compromised account.
Never embed credentials in code. An AccessKey pair hardcoded in source code is easily leaked through version control, logs, or error messages — giving attackers access to every resource in the account. Instead:
Use STS tokens for temporary, scoped access.
Store credentials in environment variables and read them at runtime.
Enable SSO for RAM users if your organization has an enterprise identity system. This allows users to log on to Alibaba Cloud through your existing identity provider.
Related topics
RAM user groups
Group RAM users to manage permissions at scale. Assigning permissions to a group rather than to individuals means you only need to update one policy when a team's access requirements change.
Security practices
Apply least-privilege permissions to groups. A group permission that is too broad amplifies the risk across every member. Overly permissive groups are one of the most common sources of unintended access.
Remove users from a group when their role changes. Leaving a user in a group they no longer need access to is a common source of permission sprawl.
Revoke group permissions when they are no longer needed. Unused permissions on a group remain a risk even if no current members actively use them.