All Products
Search
Document Center

Function Compute:Configure RAM User Permissions

Last Updated:Sep 17, 2026

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

  1. Log on to the RAM console by using an Alibaba Cloud account or a RAM user that has RAM administration permissions.

  2. Create a custom policy and select JSON Editor. For instructions, see Create a custom policy.

  3. 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.

  4. Attach the policy to the target RAM user, RAM user group, or RAM role. For RAM users, see Grant permissions to a RAM user.

  5. 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 fcsandbox custom 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 include teams/<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>

Region of the FC Agent Sandbox resource, such as cn-beijing

<account-id>

ID of the Alibaba Cloud account that owns the resource

<team-id>

Team ID

<template-id>

Template ID

<volume-id>

Volume ID

Common ARNs

Resource expression

Matching scope

*

FC Agent Sandbox resources in all regions of the account

acs:fcsandbox:<region>:<account-id>:*

All FC Agent Sandbox resources in the specified account and region

acs:fcsandbox:*:<account-id>:*

FC Agent Sandbox resources of the specified account in all regions

acs:fcsandbox:<region>:<account-id>:teams/*

Teams in the account, excluding Team child resources

acs:fcsandbox:<region>:<account-id>:teams/<team-id>

A specified Team, excluding its child resources

acs:fcsandbox:<region>:<account-id>:teams/<team-id>/*

All child resources of a specified Team, excluding the Team itself

acs:fcsandbox:<region>:<account-id>:teams/*/templates/*

Templates in all Teams

acs:fcsandbox:<region>:<account-id>:teams/*/templates/*/*

Sandboxes in all Teams

acs:fcsandbox:<region>:<account-id>:teams/<team-id>/templates/*

Templates in a specified Team

acs:fcsandbox:<region>:<account-id>:teams/<team-id>/templates/*/*

Sandboxes in a specified Team

acs:fcsandbox:<region>:<account-id>:teams/<team-id>/templates/<template-id>

A specified Template, excluding its child resources

acs:fcsandbox:<region>:<account-id>:teams/<team-id>/templates/<template-id>/*

Sandboxes created from a specified Template

acs:fcsandbox:<region>:<account-id>:teams/*/apikeys/*

API Keys in all Teams

acs:fcsandbox:<region>:<account-id>:teams/<team-id>/apikeys/*

API Keys in a specified Team

acs:fcsandbox:<region>:<account-id>:teams/*/volumes/*

Volumes in all Teams

acs:fcsandbox:<region>:<account-id>:teams/<team-id>/volumes/*

All Volumes in a specified Team

acs:fcsandbox:<region>:<account-id>:teams/<team-id>/volumes/<volume-id>

A specified Volume in a specified Team

acs:fcsandbox:<region>:<account-id>:teams/*/quotas/*

Quotas of all Teams

acs:fcsandbox:<region>:<account-id>:teams/<team-id>/quotas/*

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.