Agent Sandbox assumes a Resource Access Management (RAM) role to obtain Security Token Service (STS) temporary credentials and uses them to mount persistent storage. Create and authorize the role, and configure it for volumes and append mounts so that applications do not need long-lived AccessKey pairs in mount configurations.
How it works
When you mount persistent storage, Agent Sandbox assumes a RAM role to obtain STS temporary credentials to access storage resources such as Object Storage Service (OSS), AgenticFS, and AgenticBucket. The application does not need to provide a long-lived AccessKey pair in the mount configuration.
A RAM role requires a trust policy and a permission policy:
|
Policy |
Purpose |
|
Trust policy |
Allows the Function Compute service to assume the role. |
|
Permission policy |
Specifies the storage resources that the role can access and the actions that the role can perform. |
For the management permissions required to create, query, and delete volumes, see Volumes.
Least privilege
The permission policy of a RAM role limits the resources that can be accessed and the actions that can be performed. During a mount, Agent Sandbox further limits the permissions of the STS temporary credentials based on the storage type and the mount configuration. The permissions of the temporary credentials cannot exceed the permissions granted to the RAM role. Actual access must also comply with the authorization rules of the storage service. For more information, see the Policy parameter of AssumeRole.
Grant only the storage permissions that your workloads require. Multiple volumes can share the same RAM role, as long as the permissions cover the resources required by these mounts. A separate policy for each volume or storage path is not required. If production, test, or different workloads require separate permissions, configure separate roles.
Procedure
Step 1: Create a RAM role
-
Log on to the RAM console. In the left-side navigation pane, choose Identities > Roles, and then click Create Role.
-
Set Principal Type to Cloud Service, and set Principal Name to Function Compute/FC.
-
Enter a role name, such as
sandbox-storage-role, and then create the role. -
On the role details page, view the trust policy and make sure that the Function Compute service is allowed to assume the role.
For more information, see Create a RAM role for Alibaba Cloud services and Use a function role to access other cloud services.
Step 2: Grant permissions to access storage
-
On the Policies page of the RAM console, create a custom policy and select JSON Editor.
-
Configure the policy based on the permission configuration document for the corresponding storage type in the following table. Limit the resource scope to the storage resources that your workloads are allowed to access, and then save the policy.
-
Go back to the role details page, and in Permissions, add the permission policy that you created to the role.
|
Storage type |
Permission configuration document |
|
OSS |
The permission configuration section in Create an OSS Volume. |
|
AgenticFS |
The permission configuration section in Create an AgenticFS Volume. |
|
AgenticBucket |
The permission configuration section in Create an AgenticBucket Volume. |
When you mount multiple volumes that require a RAM role in the same Sandbox, grant the storage access permissions required by these mounts to the same RAM role. One or more permission policies can be used.
After you grant the permissions, copy the role ARN (Alibaba Cloud Resource Name) from the role details page. The role ARN is used to configure a volume or create a Sandbox.
Usage notes
Role selection rules
All storage mounts in the same Sandbox share one RAM role. Agent Sandbox does not merge the permissions of different roles. When you create a Sandbox, a role is selected in the following priority order: metadata["fc.sandbox.auth.role"] takes precedence over mountConfig.role of a volume.
|
Configuration |
Rule that takes effect |
|
metadata explicitly specifies a role. |
The RAM role specified in metadata is used, even if different roles are configured for individual volumes. |
|
metadata does not specify a role, at least one volume has a role configured, and the role ARNs of all configured volumes are the same. |
That role is used. Volumes without a configured role are excluded from the comparison, and their mounts also use that role. |
|
metadata does not specify a role, and multiple volumes have different role ARNs configured. |
Sandbox creation fails, and the system reports a role configuration conflict. |
|
Neither metadata nor any volume specifies a role. |
To mount storage that requires a RAM role, configure a valid role in metadata or in a volume first. |
Roles are compared by ARN. Two roles with different ARNs are different roles, even if they have the same permissions.
Do not set fc.sandbox.auth.role to an empty string. If you set it to an empty string, the system does not fall back to the role configured in the volume. When you mount storage that requires a RAM role, Sandbox creation fails because no valid role is available. To use the role configured in the volume, omit this field.
Role configuration for one or more volumes
The following examples show only the role configuration fields. Replace the account UID and role name in the ARN with your actual values, and then add the creation and mount parameters as described in the corresponding Volumes document. The following three configuration methods are available:
-
One volume: Specify the role in
mountConfig.roleof the volume. -
Multiple volumes that share one role: Configure the same role ARN for each volume.
-
Multiple volumes specified through metadata: Specify the role in metadata when you create the Sandbox.
One volume
When you create a volume, enter the ARN of the authorized role in mountConfig.role:
{
"mountConfig": {
"role": "acs:ram::<ACCOUNT-UID>:role/sandbox-storage-role"
}
}
When you create the Sandbox, reference the volume by name in volume_mounts and omit metadata["fc.sandbox.auth.role"] to use the role configured in the volume.
Multiple volumes that share one role
When multiple volumes must be mounted to the same Sandbox, set mountConfig.role of the volumes to the same role ARN, such as acs:ram::<ACCOUNT-UID>:role/sandbox-storage-role. This role must have the storage access permissions required by these mounts.
When you create the Sandbox, reference all of these volumes in the same creation request. Specifying the role again in metadata is not required.
Multiple volumes specified through metadata
If multiple volumes are configured with different roles, set fc.sandbox.auth.role in the metadata of the Sandbox creation request to specify one role for all mounts in this Sandbox. This role must have the access permissions required by all the mounts.
{
"metadata": {
"fc.sandbox.auth.role": "acs:ram::<ACCOUNT-UID>:role/sandbox-storage-role"
}
}
A role specified through metadata takes effect only for the Sandbox being created and does not modify the role configuration of the volumes. If an existing role already meets the permission requirements, use it directly without creating a new role.
If you provide a mount configuration directly without referencing a volume, and the target storage requires a RAM role, specify the role by using metadata["fc.sandbox.auth.role"].
Append mounts after creation
An append mount continues to use the current RAM role of the Sandbox. This role must have the permissions to access the additional storage resources. An append mount does not switch to the role configured in the volume.
If you plan to append mounts later, configure the RAM role and grant the storage access permissions required by the append mounts when you create the Sandbox:
-
If you mount a volume at creation time, use the role configured in the volume or specify a role through metadata.
-
If you do not mount a volume at creation time, configure the role through metadata.
For more information, see Append a volume mount, Append an OSS mount, Append an AgenticFS mount, and Append an AgenticBucket mount.