Realtime Compute for Apache Flink uses two separate permission systems — one for the Management Console and one for the Development Console. This document explains the permission model, the authorization process, and how to grant access based on your logon method.
When you first activate Realtime Compute for Apache Flink, the console prompts you to authorize access to cloud resources. Click Authorize in RAM on the RAM authorization page. After completing this one-time step, your Alibaba Cloud account has full access to both consoles and all related cloud product resources.
Who should read this
| If you are... | Go to |
|---|---|
| An account owner or RAM administrator setting up access for your team | Authorization process then Grant permissions by logon method |
| A developer or O&M engineer who needs access to a workspace | Ask your workspace owner to follow the instructions in Grant permissions by logon method |
| New to RAM and want to understand the concepts first | Key concepts |
Two consoles, two permission systems
Realtime Compute for Apache Flink has two distinct consoles with separate permission models:
| Console | Functions | Permission management |
|---|---|---|
| Management Console | View, create, release, and adjust workspaces; clone namespaces | Managed in the RAM console. Attach a policy to a RAM identity (RAM user or RAM role). The policy scope covers all resources under your Alibaba Cloud account. |
| Development Console | Job development, O&M, and namespace authorization within a target namespace | Managed within the Development Console itself. Assign roles to RAM users or other Alibaba Cloud accounts. The role scope covers all first-level and second-level functional permissions within the console. |
Authorization process
Whether you are granting Management Console or Development Console access, the process follows three steps:
-
Identify the target console. Determine which console the principal needs — Management Console, Development Console, or both.
-
Choose a permission level. Decide between a predefined system policy/role (for broad access) or a custom policy/role (for granular access control).
-
Grant the permissions. Follow the console-specific authorization procedure.
Quick reference: permission levels
| Console | Full access | Granular access control |
|---|---|---|
| Management Console | Grant the AliyunStreamFullAccess system policy |
Create and assign a custom policy |
| Development Console | Assign the Owner role |
Create a custom role and assign it |
For the authorization procedures, see:
Grant permissions by logon method
The Alibaba Cloud account that purchased the workspace has full access to both consoles by default — no authorization required. The instructions below apply when you need to grant access to other principals.
Alibaba Cloud account
| Target console | Authorization instructions |
|---|---|
| Management Console | Cross-account access is not allowed. |
| Development Console | Authorization method: Grant permissions for the Development Console. Principal: the ID of the other Alibaba Cloud account. |
RAM user
| Target console | Authorization instructions |
|---|---|
| Management Console | Authorization method: Grant permissions for the Management Console. Principal: the name of the RAM user. |
| Development Console | Authorization method: Grant permissions for the Development Console. Principal: the ID of the RAM user. |
RAM role
To assume a RAM role and log on with it, a RAM user must first have the AliyunSTSAssumeRoleAccess permission.
| Target console | Authorization instructions |
|---|---|
| Management Console | Authorization method: Grant permissions for the Management Console. Principal: the name of the RAM role. |
| Development Console | Authorization method: Grant permissions for the Development Console. Principal: the ID of the RAM role. |
When a RAM user assumes a RAM role, the authorized principal is always the RAM role itself — not the RAM user. For example, if flinktestA (from account A) or flinktestB (from account B) both assume the same RAM role, the principal is the RAM role in both cases.
Resource Directory member
Resource Directory (RD) members can log on through several methods. The table below shows which authorizations are needed for each.
| Logon method | Target console | Authorization required |
|---|---|---|
| Root user (Alibaba Cloud account) | Management Console | None. |
| Root user | Development Console | Typically not required. If needed, use Grant permissions for the Development Console. Principal: the ID of the root account. |
| RAM administrator (as RAM role) | Management Console | Typically not required. |
| RAM administrator (as RAM role) | Development Console | Typically not required. If needed, use Grant permissions for the Development Console. Principal: the account ID of the Resource Directory member. |
| RAM user | Management Console | Required. Authorization method: Grant permissions for the Management Console. Principal: the name of the RAM user. |
| RAM user | Development Console | Required. Authorization method: Grant permissions for the Development Console. Principal: the ID of the RAM user. |
| CloudSSO user (as RAM role) | Management Console | Use Authorization on the resource directory account. Principal: create an access configuration in CloudSSO and grant permissions to the Resource Directory account. |
| CloudSSO user (as RAM role) | Development Console | Authorization method: Grant permissions for the Development Console. Principal: the ID of the RAM role. |
| CloudSSO user (as RAM user) | Management Console | Authorization method: Grant permissions for the Management Console. Principal: the name of the RAM user synchronized from CloudSSO. |
| CloudSSO user (as RAM user) | Development Console | Authorization method: Grant permissions for the Development Console. Principal: the ID of the RAM user synchronized from CloudSSO. |
Key concepts
Account types
| Account type | Description | When to use |
|---|---|---|
| Alibaba Cloud account | The fundamental entity that owns Alibaba Cloud resources. Used for metering and billing. Has full control over all owned resources by default. | Use for purchasing and managing workspaces. Avoid using it for everyday development tasks — delegate access to RAM users or RAM roles instead. |
| RAM user | An identity representing a person or application that needs access to Alibaba Cloud. Has no permissions by default. To create a RAM user, see Create a RAM user. | Use for team members who need persistent, individual access to Alibaba Cloud resources. |
| RAM role | A virtual identity with a set of permission policies. Unlike a RAM user, a RAM role has no permanent credentials — no logon password or AccessKey pair. A trusted entity must assume the role to use its permissions. For more information, see Overview. | Use when you need temporary, assumable credentials — for example, for cross-account access or automated workloads. |
| Resource Directory member | A resource account in Resource Directory (RD), Alibaba Cloud's service for managing multi-level account and resource relationships. For more information, see What is Resource Directory. | Use for enterprise environments where workloads are isolated across multiple accounts managed under a single organization. |
Permissions
Permissions define which actions a RAM identity can perform on which resources:
-
The Alibaba Cloud account controls all permissions. Each resource has exactly one owner, which is always an Alibaba Cloud account. This account has full control over the resource. Note that a RAM identity can create a resource, but the Alibaba Cloud account remains the owner — not the creator.
-
RAM identities have no permissions by default. A RAM user or role can only access resources after the Alibaba Cloud account grants the necessary permissions.
Policies
A policy is a set of permissions defined using a specific syntax, specifying the authorized resource set, action set, and conditions. For more information, see Policy elements and Policy syntax and structure.
RAM supports two policy types:
-
System policies: Created and maintained by Alibaba Cloud. Use them as-is; they cannot be modified.
-
Custom policies: Created, updated, and managed by you. Use these for granular access control beyond what system policies provide.
Attach a policy to a RAM identity to grant the permissions it specifies. For instructions, see Grant permissions to a RAM user, Grant permissions to a RAM user group, and Manage permissions for a RAM role.