Docs

Torch Log Service

Permission management

IAM overview

TLS supports access control for managing TLS resource permissions and operations through IAM, allowing for more granular permission management. This topic describes IAM identity types, permission policies, service roles, and related information.

Introduction

The Volcengine primary account is the owner of Volcengine resources and has full management permissions over all cloud resources under this account. To ensure account security, Volcengine provides the IAM access control service to manage access permissions for different user identities to cloud resources. You can create IAM users, IAM user groups, and IAM roles using the primary account and grant them permissions to use TLS resources.

Account types

Access control IAM includes three identities: IAM users, IAM user groups, and IAM roles.

The IAM user is a type of entity identity created by the primary account or an IAM user with administrator privileges. A newly created IAM user does not have any permissions and must be authorized before accessing and managing cloud resources.

IAM user groups categorize IAM users with similar responsibilities to enhance the efficiency of managing users and their permissions.

An IAM role is a virtual user that does not have permanent credentials. It can only obtain customizable, temporary credentials (STS Token) through Security Token Service (STS). An IAM role must be assumed by a trusted entity. Once successfully assumed, the trusted entity receives the IAM role’s STS token and accesses cloud resources. For more information about STS, see Security Token Service (STS).

Setting the trusted entity as an IAM user is mainly used for cross-account access authorization or temporary authorization. For related examples, see Enable cross-account access to TLS based on IAM roles and Access logging services through STS.

Setting the trusted entity as a service is mainly used for cross-service access authorization. For related examples, see cross-service access authorization.

Permission policy

A permission policy is a set of permissions described using a syntax structure. It supports precise definition of the resource scope, operation scope, and conditions for permissions, meeting enterprise needs for the principle of least privilege. For details, see Policy overview.

Policy syntax

Policy authorization statements (Statement) related to TLS include these elements: Effect, Action, Resource, and Condition. For details, see Basic structure.

Policy categories

IAM permission policies include system preset policies and custom policies.

System preset policy

System preset policies are created and maintained exclusively by Volcanoengine. You can use them, but can not modify them. TLS supports the following two system preset policies.

TLSFullAccess: Grants permission to perform all functions and access all resources in TLS, such as creating log topics, modifying index configurations, deleting log topics, querying logs, uploading logs, and more.

TLSReadOnlyAccess: Grants read-only access to TLS. You can not create, edit, or delete resources.

Custom policy

If the system preset permission policies do not meet your requirements, you can create custom policies for more refined and minimal permission control. For example, you can allow an IAM user to view resources in a specific project or allow or prohibit permissions for certain API operations. For examples of policies related to TLS, see Custom permission policy example.

When you create a custom policy, set the actions and resources based on your actual needs. For supported actions and resources in TLS, see Authorizable operations and Authorizable resources.

Access control allows you to create custom TLS policies using a visual policy editor or a JSON editor. For details, see Create custom policy.

Notice

The primary account has permissions to call all APIs. When an IAM user initiates an API request, the user must have permissions for that API; otherwise, the API request will fail. Each API requires specific permissions, which correspond to authorization items. Only IAM users with policies containing these items can successfully call the API.

Service role

A service-linked role is an IAM role whose trusted entity is a Volcanoengine service, designed to resolve authorized access issues across cloud services. TLS supports the following service roles.

Service role	Description
ServiceRoleForTLS	The ServiceRoleForTLS role comes with a series of preset permission policies, allowing TLS to access specified resources in your account. For details, see cross-service access authorization.

Best practices

Best practices	Description
Access logging services through STS	TLS supports temporary secure access using temporary credentials provided by the Security Token Service (STS).
Set TLS access permissions through IAM	To control employees' access to TLS resources within your organization, use IAM Policy to manage permissions for different roles.
Enable cross-account access to TLS based on IAM roles	By using IAM roles, Volcanoengine account B can access log service resources in Volcanoengine account A.

Last updated: 2026.04.14 17:44:42