Docs

Torch Object Storage

Access control

How TOS authenticates requests

This topic explains how TOS authenticates requests. It will help you quickly understand the different authorization methods and choose the right one.

Authentication process

TOS uses the following process to determine whether to allow a request.

Step 1: Verify the identity

Non-anonymous requests: Verify the identity-related information included in the signature.

Anonymous requests: No identity verification is required.

Step 2: Collect request information

TOS collects the following request information to evaluate policy content:

Principal: The user or role that initiated the request.

Action: The operation that the request intends to perform.

Resource: The resource on which the request intends to operate.

Step 3: Evaluate policy content

Based on the collected request information, TOS looks up all relevant policies and makes a decision. The types of policies supported by TOS are as follows:

warning

An explicit Deny in any policy overrides an explicit Allow. If a policy contains an explicit Deny, the request is denied immediately.

Type			Description
Identity-based policies	IAM policies	Volcano Engine Identity and Access Management (IAM) controls access to cloud resources for different identities. If a request involves only identity-based policies, the policies must include at least one Allow statement.
Resource-based policies warning If a request involves both identity- and resource-based policies, the policies must contain at least one Allow statement.	Bucket policies	Bucket policies are strategies applied to individual buckets and their associated resources. You can use them to grant other users or roles permission to access these resources.
		Bucket ACLs	Bucket ACLs support the following permissions: Public read, Public read/write, and Private.
		Object ACLs	Object ACLs support the following permissions: Inherit bucket, Public read, Public read/write, and Private. If you do not specify an ACL when uploading an object and have not set a default ACL policy for objects, the ACL for that object defaults to "Private".
Other policies warning In other policies, an absence of an explicit Allow implies a Deny.	Session policies (Inline policies)	You can obtain temporary security credentials by creating a temporary session and assuming a role via the AssumeRole API. During the temporary session, you can pass an inline policy using the Policy parameter. The effective permissions for a session are determined by the intersection of the role's identity-based policies and the session policy.
		VPC policies	You can implement granular permission control for your TOS resources by configuring VPC endpoint policies and bucket policies. This allows you to restrict access to specific resources within a private network and to specific VPCs simultaneously.

Step 4: Decide whether to allow or deny

TOS makes its decision by following this process.

tip

The decision-making process in this section does not take into account VPC policies.

By default, all requests are implicitly denied access permissions, except for the root account.

If a policy contains a Deny statement, the request will be explicitly denied. If a policy contains both an Allow and a Deny statement, the Deny statement takes precedence, and the request will be denied.

An implicit denial occurs when there is no applicable Deny statement and no applicable Allow statement. Therefore, an authorization policy must include an Allow statement for authorization to succeed.

Evaluate the session policy (skip if absent). If the session policy does not explicitly Allow the request, it is implicitly denied. If it does Allow, proceed to the next step.

Evaluate the combined set of IAM policies and bucket policies:

If an explicit Deny exists, the request is denied. Otherwise, proceed to the next step.

If an explicit Allow exists, the request is permitted and the evaluation process ends.

If neither an explicit Deny nor an explicit Allow exists, it indicates an implicit denial. Proceed to the next step.

Evaluate bucket ACLs and object ACLs:

If an explicit Allow exists, access is granted.

If no explicit Allow exists, access is denied.

Last updated: 2026.01.04 11:15:05