Identity management
Direct access to ApsaraDB RDS using your Alibaba Cloud account is not recommended. Your Alibaba Cloud account has unrestricted access to all your resources — if the credentials are compromised, every resource in the account is at risk. Instead, use RAM identities (RAM users and RAM roles) to grant only the permissions each person or application actually needs.
Who should read this page
| If you are... | Go to |
|---|---|
| An account admin setting up access for your team | RAM users, RAM user groups |
| A developer or application that needs programmatic RDS access | RAM roles |
| Setting up federated access from your corporate directory | RAM users (SSO), RAM roles (SSO) |
Choose an identity type
| Identity type | Best for | Has permanent credentials? |
|---|---|---|
| RAM user | Individual people or dedicated service accounts | Yes (password and/or AccessKey pair) |
| RAM user group | Managing permissions for multiple RAM users as a unit | No |
| RAM role | Applications, services, and cross-account access | No — uses temporary Security Token Service (STS) tokens |
For applications and services, prefer RAM roles over RAM users. RAM roles issue short-lived STS tokens rather than long-term credentials, which limits exposure if a token is leaked.
RAM users
A RAM user represents a single person or application. RAM users are created by an Alibaba Cloud account or by RAM users and roles that have administrative rights. Once granted permissions, a RAM user can access resources in the parent Alibaba Cloud account through the console or API.
Access modes
When creating a RAM user, set Access Mode to one or both of:
Console Access — the user logs in with a username and password. Enable multi-factor authentication (MFA) for any user with console access.
Using permanent AccessKey to access — the user makes API calls using an AccessKey ID and AccessKey secret.
Separate console users (people) from API users (programs). This prevents an accidental console action from affecting automated workflows, and vice versa.
Security practices
Start with an admin RAM user. Use your Alibaba Cloud account to create a RAM user and grant that RAM user administrative rights. Then use the admin RAM user to create and manage other RAM users, rather than continuing to use the root Alibaba Cloud account.
Apply least privilege. Grant each RAM user only the minimum permissions required for their role. Least-privilege access limits the blast radius of a compromised account.
Never embed credentials in code. Hardcoding an AccessKey ID or AccessKey secret in source code risks leaking it through version control or logs. Use environment variables or STS tokens instead.
Enable MFA for console users. Multi-factor authentication (MFA) adds a second verification step and significantly reduces the risk of unauthorized console access.
Enable SSO when your team uses a corporate identity provider. Single sign-on (SSO) lets RAM users authenticate through your existing enterprise identity management system, centralizing authentication and simplifying offboarding.
Related topics
RAM user groups
RAM user groups let you manage permissions at the team level rather than for each individual. Assign permissions to a group once; every RAM user in that group inherits them.
Security practices
Apply least privilege to groups. Grant groups only the permissions the team's role requires. Broad group permissions can silently expand access as users are added.
Update group membership when roles change. Remove a RAM user from a group as soon as their responsibilities change. Stale group membership is a common source of unintended access.
Revoke permissions when the group no longer needs them. Audit group policies periodically and remove any that are no longer required.
Related topics
RAM roles
A RAM role is a virtual identity with attached policies but no permanent credentials — no password, no AccessKey pair. An application or service assumes a RAM role and receives a temporary STS token. When the token expires, the application must request a new one.
This model is preferable to long-term AccessKey pairs for applications because a leaked STS token automatically expires.
How it works
Grant a trusted entity permission to call the AssumeRole API operation.
The trusted entity calls
AssumeRoleand receives a temporary STS token.The trusted entity uses the STS token to access ApsaraDB RDS resources as that RAM role.
When the token expires, the trusted entity requests a new one.
Security practices
Set an appropriate STS token validity period. The maximum validity period of an STS token equals the maximum session duration configured for the role — set that duration to an appropriate value to reduce security risks.
Avoid changing the trusted entity of a RAM role after creation. Changing the trusted entity can cause permission loss that disrupts your services, or introduce privilege escalation if a new trusted entity gains unintended access. Test any such changes in a non-production environment before applying them.
Enable SSO for role-based access. If your organization uses a corporate identity provider, SSO lets users assume RAM roles through your existing identity management system.