Enterprises typically use one Alibaba Cloud account to own cloud resources and use RAM users, RAM user groups, or RAM roles to delegate management permissions. This topic explains how to limit FC Agent Sandbox permissions to specified resource groups, Teams, or resource types based on common scenarios. The commonly used terms "main account" and "sub-account" refer to an Alibaba Cloud account and a RAM user, respectively, in this topic.
Choose an authentication method
Use the console or OpenAPI
Use an Alibaba Cloud account or RAM user to manage Teams, API Keys, and other resources in the console. Use Alibaba Cloud AK or STS temporary credentials to call FCSandbox OpenAPI. Both methods use RAM policies to control the allowed operations and resources.
Use the E2B SDK, CLI, or compatible APIs
Use an FC Agent Sandbox API Key to create and access sandboxes through the E2B SDK, E2B CLI, or compatible HTTP APIs. FCSandbox RAM permissions are not required. Each API Key is bound to one Team. Use separate Teams and API Keys for different projects and environments, and do not share an API Key between test and production applications. For instructions, see Create an API Key.
Plan resources and permissions
When multiple departments share one Alibaba Cloud account, create a resource group for each department and create a Team for each project and environment. For example:
Alibaba Cloud account
├── Resource group: Department A
│ ├── Team: Data analytics project - test environment
│ ├── Team: Data analytics project - production environment
│ ├── Team: Machine learning project - test environment
│ └── Team: Machine learning project - production environment
└── Resource group: Department B
Recommended permission scopes:
|
Identity |
Recommended permission scope |
|
FC Agent Sandbox platform administrator |
All FC Agent Sandbox resources in the account |
|
Department administrator |
The resource group of the department |
|
Project developer |
The test Team of a specified project |
|
Production operator |
The production Team of a specified project |
|
Business application |
Only the FC Agent Sandbox API Key of the corresponding Team |
Use resource groups as permission boundaries for departments, and use Teams as permission boundaries for projects and environments. Place test and production environments in separate Teams, and use Team-level RAM permissions to prevent developers from modifying production resources. For Team resource relationships, see Create a Team.
Configure RAM permissions
-
Log on to the RAM console by using an Alibaba Cloud account or a RAM user that has RAM administration permissions.
-
Create a custom policy and select JSON Editor. For instructions, see Create a custom policy.
-
Replace the resource group IDs and Team IDs in the policy for your scenario. If the policy uses a Resource ARN, also replace the region and account ID.
-
Attach the policy to the target RAM user, RAM user group, or RAM role. For RAM users, see Grant permissions to a RAM user.
-
Use the target RAM identity to verify that required operations succeed and operations outside the authorized scope are denied.
Manage all FC Agent Sandbox resources in an account
This scenario applies to a platform administrator who manages all Teams and resources. The following policy grants FCSandbox permissions in all regions of the account. It does not grant permissions on Function Compute or other Alibaba Cloud services. To limit the policy to one region, change Resource to acs:fcsandbox:<region>:<account-id>:*:
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": "fcsandbox:*",
"Resource": "*"
}
]
}
Manage a specified resource group
This scenario applies to an administrator who manages the test and production Teams of all projects in one department but cannot access other departments. The following example limits permissions to the department's resource group:
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": "fcsandbox:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"acs:ResourceGroupId": "<department-resource-group-id>"
}
}
}
]
}
After logging on to the console, the RAM user must switch to an authorized resource group. When calling list operations, also specify the corresponding resourceGroupID.
Manage a specified Team
This scenario applies to project developers or production operators. The following policy allows management of the specified Team and its child resources, but does not allow the identity to create other Teams:
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": "fcsandbox:*",
"Resource": [
"acs:fcsandbox:<region>:<account-id>:teams/<team-id>",
"acs:fcsandbox:<region>:<account-id>:teams/<team-id>/*"
]
}
]
}
The Team and its child resources use separate ARNs, so both Resource entries are required. This policy does not include account-level Team list permissions. If the user must select a Team in the console, add fcsandbox:ListTeams permission scoped to the resource group. The user can then see the Team list in the same resource group. To strictly limit Team visibility, use a separate resource group for the project.
Verify permissions
After configuration, verify both allowed and denied operations:
|
Identity |
Expected to be allowed |
Expected to be denied |
|
Platform administrator |
Manage all Teams and resources in the account |
Resources of other accounts |
|
Department administrator |
Manage Teams and resources in the department's resource group |
Resource groups of other departments |
|
Project developer |
Manage the test Team of the specified project |
Other projects and production Teams |
|
Production operator |
Manage the production Team of the specified project |
Test Teams and other production Teams |
|
Business application |
Create and access sandboxes by using an API Key |
Manage Teams, API Keys, or Volumes through OpenAPI |
Common mistakes
-
Sharing one Team across all projects: Project members cannot effectively isolate API Keys, Templates, sandboxes, and Volumes. Use a separate Team for each project and environment.
-
Granting developers access to the entire department resource group: A department resource group contains both test and production Teams. Resource group authorization would also grant developers access to production resources. Limit developer permissions to specified test Teams.
-
Using AdministratorAccess for convenience: This policy grants permissions beyond FC Agent Sandbox. Use an
fcsandboxcustom policy when the identity only manages FC Agent Sandbox. -
Confusing RAM permissions with FC Agent Sandbox API Keys: RAM permissions control the console and OpenAPI. API Keys are used by the E2B SDK, CLI, and compatible HTTP APIs.
-
Authorizing only a Team or only its child resources:
teams/<team-id>does not includeteams/<team-id>/*. Configure both when managing the whole Team. -
Ignoring list permission scope: List operations may use collection ARNs. Before granting collection permissions, confirm whether the user should be able to see all resources in that scope.
Permission policy reference
Action
Action in a permission policy specifies which FC Agent Sandbox OpenAPI operations a RAM identity can call. The format is:
fcsandbox:<action>
For example, CreateTeam corresponds to fcsandbox:CreateTeam, and CreateVolume corresponds to fcsandbox:CreateVolume. Before configuring a policy, find the required operation in the FC Agent Sandbox OpenAPI documentation and configure Action based on its authorization information.
Resource ARN
ARN format
acs:fcsandbox:<region>:<account-id>:<resource-path>
|
Placeholder |
Description |
|
|
Region of the FC Agent Sandbox resource, such as |
|
|
ID of the Alibaba Cloud account that owns the resource |
|
|
Team ID |
|
|
Template ID |
|
|
Volume ID |
Common ARNs
|
Resource expression |
Matching scope |
|
|
FC Agent Sandbox resources in all regions of the account |
|
|
All FC Agent Sandbox resources in the specified account and region |
|
|
FC Agent Sandbox resources of the specified account in all regions |
|
|
Teams in the account, excluding Team child resources |
|
|
A specified Team, excluding its child resources |
|
|
All child resources of a specified Team, excluding the Team itself |
|
|
Templates in all Teams |
|
|
Sandboxes in all Teams |
|
|
Templates in a specified Team |
|
|
Sandboxes in a specified Team |
|
|
A specified Template, excluding its child resources |
|
|
Sandboxes created from a specified Template |
|
|
API Keys in all Teams |
|
|
API Keys in a specified Team |
|
|
Volumes in all Teams |
|
|
All Volumes in a specified Team |
|
|
A specified Volume in a specified Team |
|
|
Quotas of all Teams |
|
|
Quotas of a specified Team |
A Sandbox does not have an independent Resource ARN that contains a Sandbox ID. A Template uses templates/<template-id>, while sandboxes created from that Template use templates/<template-id>/*. Resource determines the accessible Template or Sandbox scope, while Action determines which Template or Sandbox operations are allowed.
API Keys and quotas support only Team-level authorization and cannot be limited to a single API Key or quota record. Depending on the request scope, list operations may use an account-level or Team-level collection ARN. If an identity has only Team-level permissions, explicitly specify the Team ID when calling a list operation that supports it.