Identity management
Access DataWorks as a RAM (Resource Access Management) user or RAM role rather than using your Alibaba Cloud account directly. Your Alibaba Cloud account has unrestricted access to all resources — a leaked credential exposes everything. RAM users and RAM roles give you fine-grained control and limit the blast radius of a security incident.
Identity types at a glance
| Identity type | Description | Best for |
|---|---|---|
| RAM user | A named identity with its own credentials (logon password or AccessKey pair). Belongs to an Alibaba Cloud account. | Individual team members and service accounts |
| RAM user group | A collection of RAM users that share the same permissions. | Managing permissions for a team or functional role |
| RAM role | A virtual identity with no permanent credentials. Activated by assuming the role via a temporary Security Token Service (STS) token. | Automated workloads, cross-account access, and programmatic integrations |
RAM users
A RAM user can be created by an Alibaba Cloud account or by a RAM user or RAM role that has administrative rights. Once created and granted the appropriate permissions, a RAM user can access Alibaba Cloud resources through the Alibaba Cloud Management Console or by calling API operations.
Best practices
Separate human users from service accounts. When you create a RAM user, set the Access Mode to Console Access for human users, Using permanent AccessKey to access for programs and scripts, or both. Mixing both access modes in a single account means a developer who leaves your team could break an automated pipeline — or an automated job could inadvertently affect a user's permissions.
Start with an admin RAM user, not the root account. Use your Alibaba Cloud account once to create a RAM user with administrative rights. Use that RAM user for all subsequent user management. This keeps your root account credentials off the keyboard.
Apply least privilege. Grant only the permissions a RAM user needs for their current role. Overly broad permissions increase the risk of accidental or malicious changes. Revisit permissions when responsibilities change.
Require MFA for console users. Enable multi-factor authentication (MFA) for any RAM user that logs in through the console. MFA blocks most credential-stuffing attacks even if a password is compromised.
Never hardcode credentials. Do not embed an AccessKey ID or AccessKey secret in source code or configuration files. A credential leaked through a repository or a build log exposes every resource in the account. Use STS tokens or environment variables instead. See Credential security solutions.
Enable SSO if your organization uses an identity provider. Single sign-on (SSO) lets RAM users log in through your enterprise identity management system instead of managing separate Alibaba Cloud passwords. See Overview of user-based SSO.
Related topics
RAM user groups
Group RAM users by function or team to manage permissions at scale. Instead of granting permissions to each user individually, grant them to the group — every member inherits the same access.
Best practices
Apply least privilege at the group level. Grant only the permissions the group needs. Avoid granting broad permissions to a group and expecting individuals to self-limit.
Remove users when their role changes. If a team member moves to a different team or project, remove them from the group before the transition takes effect. Permissions that outlast a role create unintended access.
Revoke permissions when the group no longer needs them. Audit group permissions regularly and remove any that are no longer required. Stale permissions accumulate over time and expand your attack surface.
Related topics
RAM roles
A RAM role is a virtual identity — it has no permanent logon password or AccessKey pair. To use a RAM role, a trusted entity assumes it, which returns a short-lived STS token. The trusted entity uses that token to access Alibaba Cloud resources as the role for the duration of the session.
RAM roles are well-suited for automated workloads:
| Use case | Example |
|---|---|
| Scheduled jobs and ETL (extract, transform, load) pipelines | Run data processing tasks without distributing long-lived credentials |
| CI/CD pipelines | Deploy DataWorks resources automatically as part of your release workflow |
| Cross-account access | Allow a RAM user in one account to access resources in another account |
| Application integrations | Connect external systems to DataWorks using short-lived, scoped tokens |
Best practices
Lock down the trusted entity after creation. Changing the trusted entity of an existing RAM role can cause permission loss and disrupt running workloads. Adding a new trusted entity can introduce privilege escalation risks. Test any changes in a non-production environment before applying them to a production role.
Set the session duration to the minimum needed. After a trusted entity calls AssumeRole, the returned STS token is valid for the duration you configure. Keep this as short as practical. The maximum token validity equals the maximum session duration set on the role — set that value carefully to reduce the window of exposure if a token is leaked.
Enable SSO for roles if your organization uses an identity provider. Role-based SSO lets your enterprise identity management system map users to RAM roles, so access follows your existing organizational structure. See Role-based SSO.