To control employees' access to TLS resources within an enterprise, you can use IAM Policy to manage and restrict permissions for different job roles. This example demonstrates how to use IAM Policy to control the permissions of different employees for various functional modules and resources in TLS.

Background

Enterprises typically have positions such as system administrator, development engineer, operations engineer, product operations specialist, and data analyst. Each position has clearly defined responsibilities, and personnel in each role should have different access permissions to TLS resources. Permission policies should be promptly adjusted when job roles change.

For this scenario, you can manage the scope of permissions for each role in the following ways.

Create a corresponding IAM user group for each position, add permission policies, and grant the user group the permissions required to perform relevant operations.

Create IAM users for enterprise employees and add each IAM user to the appropriate user group according to their position.

Adjust permission policies promptly based on job requirements.

For example, if IAM users in the development user group require broader permissions, you can directly modify the permission policy for the user group, which will apply to all IAM users in that group.

Adjust user groups promptly according to changes in employees' job roles.

For example, if a development engineer's position changes to product operations specialist, move their IAM user from the development user group to the product operations user group.

The corresponding user groups and permission scopes for each position are as follows:

Role	User group	Responsibilities and permission scope
Operations administrator	None	The Volcengine primary account has all permissions for TLS and is responsible for permission management. Can create IAM users, user groups, and custom authorization policies.
Operations engineer	SysOM	Responsible for maintaining online systems and promptly identifying issues when exceptions occur. For example, collect website access logs and configure alarm policies for access failures, so that issues can be quickly identified and investigated when users encounter widespread errors. Can be granted permissions to manage basic TLS resources, create and manage collection configurations, alarm policies, query and analysis, and dashboards. Including: Resource management: Permissions to manage the project and log topics. Log collection: Create and manage collection configurations and host groups, and collect log data using various methods. Query and analysis: Permissions to configure and manage indexes, query logs, download logs, and all other query and analysis-related permissions. Alarm: Permissions to create and manage notification groups, alarm policies, and all other alarm-related permissions. Dashboard: Permissions to create and manage dashboards.
Development engineer	SysRD	Assist operations personnel in troubleshooting online issues. All query, alarm, and dashboard permissions for all IAM Projects can be granted to facilitate viewing dashboards and detailed logs, and troubleshooting online issues. Includes: Query and analysis: Permissions to configure and manage indexes, query logs, download logs, and all other query and analysis-related permissions. Alarm: Permissions to create and manage notification groups, alarm policies, and all other alarm-related permissions. Dashboard: Permissions to create and manage dashboards.
Operations/BI	ProductBI	Configure and view operations dashboards, for example, create business dashboards for websites and collect statistics on website visits, including UV, PV, traffic sources, top ten visited pages, and more. Grant log query and dashboard management permissions for specified IAM Projects to facilitate creating real-time operations dashboards and identifying overall product performance and related data. Includes: Query and analysis: Permissions to query logs. Dashboard: Permissions to create and view dashboards.

Steps

Step 1: Create an IAM user group

An IAM user group is a collection of IAM users and is used to centrally manage users' permissions. When a user group is bound to a permission policy, all users in the group will have the corresponding permissions. You can refer to the following steps to create an IAM user group for each position.

The operations administrator logs in to the IAM console using the primary Volcano Engine account.

In the left navigation bar, select User management > User group.

Create the operations engineer user group SysOM.

Click Create new user group.

Set User group name to SysOM, and click Submit.

Follow the steps above to create the R&D engineer user group SysRD and the Operations & BI user group ProductBI in sequence.

Step 2: Create a custom policy and bind it to a user group

The permission types in IAM include system predefined policies and user-defined policies. If the system predefined policies do not meet business requirements, you need to create a custom policy in advance. TLS provides common access policy examples for your reference. For details, please refer to Custom permission policy example. For the steps to create a custom policy, please refer to Create policy.

In the left navigation bar, click Permission policy.

Create the corresponding custom policy for the operations engineer user group SysOM.

Click Create policy.

Set the policy name and policy content, and click Submit.

Set Policy name to SysOMPolicy. For the policy content, please refer to the following policy example. You can also refer to Custom permission policy example to set permission policies with different levels of control.

Operations access policy example: Grant the IAM user group SysOM management permissions for all log projects and log topics, management permissions for all collection configurations and host groups, permissions to configure and manage indexes, query logs, download logs, all query and analysis permissions, and permissions to create and manage notification groups, alarm policies, and dashboards.

{
"Statement": [
{
"Effect": "Allow",
"Action": [
"TLS:CreateProject",
"TLS:CreateTopic",
"TLS:PutLogs",
"TLS:WebTracks",
"TLS:DeleteTopic",
"TLS:ModifyTopic",
"TLS:DescribeDownloadTasks",
"TLS:DescribeShards",
"TLS:DescribeTopic",
"TLS:DescribeTopics",
"TLS:DeleteProject",
"TLS:ModifyProject",
"TLS:DescribeProject",
"TLS:DescribeConsumerGroups",
"TLS:DescribeProjects",
"TLS:DescribeRules"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"tls:CreateRule",
"tls:DeleteRule",
"tls:ModifyRule",
"tls:DescribeRule",
"tls:DescribeRules",
"tls:ApplyRuleToHostGroups",
"tls:DeleteRuleFromHostGroups",
"tls:CreateHostGroup",
"tls:DeleteHostGroup",
"tls:ModifyHostGroup",
"tls:DescribeHostGroup",
"tls:DescribeHostGroups",
"tls:DescribeHosts",
"tls:DeleteHost",
"tls:DescribeHostGroupRules",
"tls:ModifyHostGroupsAutoUpdate",
"tls:DeleteAbnormalHosts"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"tls:DescribeIndex",
"tls:CreateIndex",
"tls:DeleteIndex",
"tls:ModifyIndex",
"tls:SearchLogs",
"tls:DescribeHistogram",
"tls:DescribeLogContext"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"tls:CreateDownloadTask",
"tls:DescribeDownloadTasks",
"tls:DescribeDownloadUrl",
"tls:CancelDownloadTask"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"tls:CreateAlarmNotifyGroup",
"tls:DeleteAlarmNotifyGroup",
"tls:DescribeAlarmNotifyGroups",
"tls:ModifyAlarmNotifyGroup",
"tls:DescribeAlarmNotifyGroup",
"tls:CreateAlarm",
"tls:DeleteAlarm",
"tls:DescribeAlarms",
"tls:DescribeAlarm",
"tls:ModifyAlarm",
"tls:DescribeAlarmLogs",
"tls:ManualTriggerAlarm",
"tls:DescribeManualTriggerAlarmTask",
"tls:ModifyAlarmIncident",
"tls:DescribeAlarmIncident",
"tls:DisableAlarm",
"tls:EnableAlarm",
"tls:CreateAlarmContentTemplate",
"tls:DeleteAlarmContentTemplate",
"tls:DescribeAlarmContentTemplates",
"tls:ModifyAlarmContentTemplate",
"tls:CreateAlarmWebhookIntegration",
"tls:DeleteAlarmWebhookIntegration",
"tls:DescribeAlarmWebhookIntegrations",
"tls:ModifyAlarmWebhookIntegration"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"tls:CreateDashboard",
"tls:DeleteDashboard",
"tls:ModifyDashboard",
"tls:DescribeDashboard",
"tls:DescribeDashboards"
],
"Resource": [
"*"
]
}
]
}

R&D access policy example: Grant the IAM user group SysRD permissions to configure and manage indexes, query logs, download logs, all query and analysis permissions, and permissions to create and manage notification groups, alarm policies, and dashboards.

{
"Statement": [
{
"Effect": "Allow",
"Action": [
"tls:DescribeProjects",
"tls:DescribeProject",
"tls:DescribeTopics",
"tls:DescribeTopic"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"tls:DescribeIndex",
"tls:CreateIndex",
"tls:DeleteIndex",
"tls:ModifyIndex",
"tls:SearchLogs",
"tls:DescribeHistogram",
"tls:DescribeLogContext"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"tls:CreateDownloadTask",
"tls:DescribeDownloadTasks",
"tls:DescribeDownloadUrl",
"tls:CancelDownloadTask"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"tls:CreateAlarmNotifyGroup",
"tls:DeleteAlarmNotifyGroup",
"tls:DescribeAlarmNotifyGroups",
"tls:ModifyAlarmNotifyGroup",
"tls:DescribeAlarmNotifyGroup",
"tls:CreateAlarm",
"tls:DeleteAlarm",
"tls:DescribeAlarms",
"tls:DescribeAlarm",
"tls:ModifyAlarm",
"tls:DescribeAlarmLogs",
"tls:ManualTriggerAlarm",
"tls:DescribeManualTriggerAlarmTask",
"tls:ModifyAlarmIncident",
"tls:DescribeAlarmIncident",
"tls:DisableAlarm",
"tls:EnableAlarm",
"tls:CreateAlarmContentTemplate",
"tls:DeleteAlarmContentTemplate",
"tls:DescribeAlarmContentTemplates",
"tls:ModifyAlarmContentTemplate",
"tls:CreateAlarmWebhookIntegration",
"tls:DeleteAlarmWebhookIntegration",
"tls:DescribeAlarmWebhookIntegrations",
"tls:ModifyAlarmWebhookIntegration"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"tls:CreateDashboard",
"tls:DeleteDashboard",
"tls:ModifyDashboard",
"tls:DescribeDashboard",
"tls:DescribeDashboards"
],
"Resource": [
"*"
]
}
]
}

Operations/BI access policy example: Grant the IAM user group ProductBI permissions to query logs and create and manage dashboards.

{
"Statement": [
{
"Effect": "Allow",
"Action": [
"tls:DescribeProjects",
"tls:DescribeProject",
"tls:DescribeTopics",
"tls:DescribeTopic"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"tls:SearchLogs",
"tls:DescribeIndex",
"tls:DescribeSavedSearches",
"tls:DescribeHistogram"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"tls:CreateDashboard",
"tls:DeleteDashboard",
"tls:ModifyDashboard",
"tls:DescribeDashboard",
"tls:DescribeDashboards"
],
"Resource": [
"*"
]
}
]
}

Click Add permission.

On the User group tab, find and select the user group SysOM that you created in Step 1.

Click Submit.

Refer to the steps above to create the custom policy SysRDPolicy for R&D engineers and bind it to the user group SysRD, and create the custom policy ProductBIPolicy for operations/BI, but do not bind it to a user group. This policy will be used for subsequent binding to an IAM project.

Step 3: Create IAM users and add them to user groups

An IAM user is an entity identity in IAM. Each IAM user can correspond to an employee, system, or application within the enterprise. An IAM user is not an independent Volcano Engine account and does not own any resources. All resources created by IAM users are billed to the associated Volcano Engine account.

The steps for creating IAM users and granting permissions are as follows:

In the left navigation bar, select User management > Users.

Create an operations engineer user named Jason.

Click Create new user and select Create user.

Set the basic information and login settings as prompted on the page, then click Next.

For example, set the Username to Jason, and enable Programmatic access and Console access permissions.

Fill in the Permission settings and click Next.

On the Add to user group tab, bind the user group SysOM.

After confirming the information, click Next and follow the on-screen instructions to complete user creation.

Refer to the steps above to create R&D engineer users and operations and BI users in turn, and bind them to the corresponding user groups.

Step 4: Create IAM projects and bind user groups

IAM projects are used for grouping and managing cloud resources by business department or project dimension. After operations personnel create collection configurations and set indexes, they can record the website access log data required for product operations in the project and log topic where the data is located. The operations administrator can add these resources to the IAM project ProjectNginx, and bind the user group ProductBI for product operations and the access policy ProductBIPolicy to this IAM project. Members of the user group will only have the specified access permissions for the specified resources in this project.

The steps for creating IAM projects and binding user groups are as follows:

In the left navigation bar, select Resource Project > Project Management.

Create the project ProjectNginx.

Click Create Project, set the Project Name to ProjectNginx, and click OK.

Bind a log project and a log topic to ProjectNginx.

Here, log project 8e87681c-99**** and log topic cbae73d1-f917-**** are used as examples.

Find ProjectNginx in the project list and click the project name.

On the Manage Resources tab, select the specified log project and log topic.

You can filter by Resource Type and Region. If other IAM projects were already bound when creating the log project, you can use the Resource transfer in feature to migrate resources to the current IAM project. For detailed steps, refer to Project Resource Management.

Bind the IAM user group ProductBI to the project.

On the permission policy tab, click Add Permission.

Follow the interface prompts to select the user group ProductBI and specify the permission policy as ProductBIPolicy.

Click OK.

Step 5: Each role accesses specified resources within the permission scope

After completing the above configuration, personnel in each role can access specified resources within the assigned permission scope via the console or API.

Torch Log Service