Overview
In enterprise multi-team collaboration scenarios, a root account needs to allocate differentiated resource access permissions to sub-users from different teams, allowing them to view and manage only specified resources on Tencent Cloud TI-ONE Platform (TI-ONE) and other associated cloud resources, such as Cloud File Storage (CFS) instances. To achieve effective resource isolation, you can categorize and authorize resources using tag-based authorization and configure corresponding policies in Cloud Access Management (CAM).
Scenario Description
Taking resource groups and online services as examples, assume that a root account has two teams using the TI-ONE product, with two resource groups, two online services, and two CFS instances. The following table shows the corresponding information.
|
rsg-wwb2hgrs | llm_text | team:llm_text | llm text team |
rsg-zbqrjvlz | llm_picture | team:llm_picture | llm_picture Team |
Expected Outcome
Resources such as resource groups and online services are isolated between sub-users.
1. Resource group
When you use an administrator account to view the resource group list in the Shanghai region, all resource groups are displayed.
When you use the llm_text_user account to view the resource group list in the Shanghai region, only resource groups bound to the team:llm_text tag can be viewed.
2. Online service
When you use an administrator account to view the online service list in the Shanghai region, all online services can be viewed. When you use the llm_text_user account to view the online service list in the Shanghai region, only online services bound to the team:llm_text tag can be viewed.
Prerequisites
You Have Confirmed That the APIs Support Resource-Level Access Control
The prerequisite for implementing tag-based authorization is that the APIs must support resource-level access control. Currently, most TI-ONE resources support resource-level authorization.
You Have Created Sub-users and Granted Permissions
Create and authorize the CAM sub-user llm_text_user for the llm_text team in advance, and create and authorize the CAM sub-user llm_picture_user for the llm_picture team.
Operation Steps
Step 1: Creating a Tag and Binding It to Resources
This step primarily prepares tag rules for subsequent permission configuration to achieve resource categorization.
1. Create a tag
Go to the tag list page, click New Tag, enter the tag key and value, then click OK to create it successfully.
2. Add a tag to the resource group
On the resource group management page, select the resource group to be tagged, click Edit, choose the previously created team tag key, bind the corresponding tag values respectively, and click OK to complete.
3. Add a tag to the online service
Select the service to be tagged on the Model Service - Online Service page, click Edit Tag, select the previously established team tag key in the tags, bind the corresponding tag values respectively, and click Yes.
Step 2: Create Custom Policy
You can write custom policies to meet your permission requirements. This step involves creating custom policies to ensure sub-accounts of different teams can only access the specific resources they are authorized for.
APIs of TI-ONE vary in permission control granularity: some support tag-based resource-level authorization, while others only support API-level general access control. Furthermore, when executing AI tasks, the platform relies on other cloud services (such as querying CFS instances), requiring corresponding service authorization. Therefore, to achieve resource isolation for TI-ONE, you need to configure the following three policies:
Number | Policy Name | Category | Policy Description |
1 | Policy_llm_text_tag | Custom policy | Policy used when TI-ONE APIs support tag-based resource-level authorization |
2 | Policy_tione_required | Custom policy | Policy used when TI-ONE features rely on the APIs of other cloud products |
3 | QcloudTIONEOperationalPrecondition | Preset policy | Policy used when TI-ONE APIs support API-level authorization |
1. Create the custom policy Policy_llm_text_tag.
Go to the CAM policy page and click Create Custom Policy.
Select Authorization by Tag.
On the Edit Policy page, select Visual Policy Generator.
Service (required): Select the product to authorize: TI-ONE (tione).
Operation (required): Select the operation you want to authorize. Here, "all operations (tione:*)" is selected by default.
Select a tag (required): Select the team tag key and llm_text tag value created in the previous step 1.
Select Condition Key: resource_tag is selected by default with the condition operator set to OR. request_tag is not selected by default.
Whether to grant the permission "resource" (required): "*" for APIs that do not support tags: Select No.
Description
All APIs of the service are included in the operations allowed. You can use Whether Authorization by Tag to filter APIs and check whether they support tag-based authorization.
Yes: APIs support authorization by tag and have the operation permissions for resources associated with the tags.
No: APIs do not support authorization by tag and have operation permissions on all resources.
click Next, enter the Associate User/User Group/Role page.
The policy name is automatically generated by the console. The default name is policygen. The suffix number is generated based on the creation date. In this example, change the policy name to Policy_llm_text and click Complete.
2. Create the custom policy Policy_tione_required.
Go to the CAM policy page and click Create Custom Policy. Select Authorization via Policy Syntax.
Select the blank template and click Next.
Change the Policy Name to Policy_tione_required and modify the Policy Content as follows. Then click Complete. This policy is modified based on the preset policy QcloudTIONEFullAccessContainMultiservice. The action "tione:*" and financial payment policy "finance:trade" have been removed. Other actions can be adjusted as needed according to the table in the Appendix: API Description. By default, all resource permissions are granted: "resource": "*". For tag-based resource permission management, use custom policies with tag-based authorization.
{
"statement": [
{
"action": [
"cam:GetRole",
"cam:ListAttachedRolePolicies",
"vpc:DescribeVpcEx",
"vpc:DescribeSubnetEx",
"vpc:DescribeNetworkAcls",
"vpc:DescribeSecurityGroupPolicies",
"cls:DescribeLogsets",
"cls:DescribeTopics",
"tcr:DescribeInstances",
"tcr:DescribeNamespaces",
"tcr:DescribeRepositories",
"tcr:DescribeRepositoryOwnerPersonal",
"tcr:DescribeRepositoryFilterPersonal",
"tcr:DescribeNamespacePersonal",
"tcr:DescribeInternalEndpoints",
"monitor:GetMonitorData",
"cos:GetService",
"cos:GetObject",
"cos:GetBucket",
"cos:HeadObject",
"cos:OptionsObject",
"cos:PutObject",
"tag:DescribeTagKeys",
"tag:DescribeTagValues",
"tag:AttachResourcesTag",
"tag:DetachResourcesTag",
"tag:GetResources",
"tag:DescribeEffectivePolicy",
"cfs:DescribeCfsFileSystems",
"emr:DescribeInstances",
"cvm:DescribeAddresses",
"cvm:DescribeInstances",
"emr:DescribeInstancesList",
"cfs:DescribeMountTargets",
"goosefs:DescribeClusters",
"goosefs:DescribeNamespaces",
"goosefs:DescribeFileSystems",
"cvm:DescribeSecurityGroupPolicys",
"clb:DescribeListeners",
"clb:DescribeLoadBalancers",
"cam:ListMaskedSubAccounts",
"monitor:DescribeAlarmPolicies",
"vpc:DescribeSecurityGroupLimits",
"cam:ListGroupsForConsole"
],
"effect": "allow",
"resource": "*"
}
],
"version": "2.0"
}
Step 3: Policy Association with Sub-User
This step is primarily used to associate the custom policies and preset policy created in the preceding step with the sub-users.
On the User List page, locate the sub-user llm_text_user and click the Authorize button on the right.
Select Policy_llm_text_tag, QcloudTIONEOperationalPrecondition and Policy_tione_required, then click Complete.
If you need to associate user groups, you can also find the user group to which you want to associate policy permissions on the User Group List page, click to go to the user group details page, select the Associate Policy option below, select the three policies mentioned above, and click OK.
Note:
1. Ensure that the sub-user is not associated with other CAM policies for TI-ONE. Since CAM policies are combined into a union, other TI-ONE policies may cause resource isolation to fail.
Step 4: Creating a Tag Policy
This step is primarily used to achieve automated tag management. Based on a user's tags, the system automatically associates the user's tag key-value pairs during product operations. Tag policies enable automatic association of tags when resources are created or modified. For specific configuration, see Creating Tag Policies. Note:
Select the tag team:llm_text created in Step 1 of this section. Enter the tag key team.
For Product Region, select All Products.
Enable auto-assignment and enforce.
After creation, select this policy and bind it to the corresponding sub-account.
Step 5: Verifying
This step is primarily used to verify whether the preceding steps have taken effect.
Log in to the TI console as the Sub-user llm_text_user associated with the policy. The Sub-user can only view and operate resources associated with the tag team:llm_text. The expected outcome is met.
Authorize the llm_picture team using the same authorization method as above.
Isolation of CFS Instances and Other Storage Resources
Two methods are available for CFS storage resource isolation. Select an isolation method based on your actual usage scenario.
Method 1: CFS Instance Isolation
When different teams require a higher level of data security and performance isolation, resource isolation can be implemented at the CFS instance level. The specific method is: create an independent CFS instance for each team, and then use the tag-based authorization feature to grant each team's sub-accounts the permissions to access only the CFS instance with specified tags. For specific operation steps, see CAM > Creating Custom Polices Through Tag Authorization. Method 2: Controlling CFS Mount Permissions at the Directory Level
When multiple teams need to share the same CFS instance while data directory isolation is required, access can be controlled at the directory level. The specific method is: create independent root directories for different teams within the same CFS instance. When data sources are configured on TI-ONE, specify the mount directory accessible to each team.
Must-Knows
Note:
1. When a sub-account uses a custom policy, if an API permission error occurs for a specific feature on the platform, it is generally because product iteration has introduced new cloud product APIs. You can add the corresponding API permissions to the custom policy based on the error message.
2. If the user is the resource creator, they are not subject to the restrictions of tag rules.
Appendix: API Description
API description for the Policy_tione_required policy
Note: Pay special attention to the authorization scope for fields in bold and proceed with caution. Use tags to control the authorization scope when necessary.
Category | API Name | API Description |
cam | GetRole | Queries user group details. |
cam | ListAttachedRolePolicies | -- |
cam | ListMaskedSubAccounts | Queries a list of sub-accounts (with sensitive information masked). |
cam | ListGroupsForConsole | Queries a list of user groups in the console. |
cfs | DescribeCfsFileSystems | Queries file systems. |
cfs | DescribeMountTargets | Queries file system mount points. |
clb | DescribeListeners | Queries a list of Cloud Load Balancer (CLB) listeners. |
clb | DescribeLoadBalancers | Queries a list of CLB instances. |
cls | DescribeLogsets | Queries a list of logsets. |
cls | DescribeTopics | Queries a list of log topics. |
cos | GetService | Queries a list of buckets. |
cos | GetObject | Downloads objects. |
cos | GetBucket | Queries objects in a bucket. |
cos | HeadObject | Checks whether an object exists and returns basic information if it does. |
cos | OptionsObject | Sends a preflight request for cross-origin resource sharing (CORS). |
cos | PutObject | Uploads objects. |
cvm | DescribeAddresses | Queries elastic IP addresses (V3). |
cvm | DescribeInstances | Queries a list of instances. |
cvm | DescribeSecurityGroupPolicys | Queries security group rules. |
emr | DescribeInstances | Queries Elastic MapReduce (EMR) instances. |
emr | DescribeInstancesList | Queries a list of EMR cluster instances. |
goosefs | DescribeClusters | Queries all Data Accelerator Goose FileSystem (GooseFS) clusters. |
goosefs | DescribeNamespaces | Lists all namespaces. |
goosefs | DescribeFileSystems | Lists all file systems. |
monitor | GetMonitorData | Pulls the monitoring data. |
monitor | DescribeAlarmPolicies | Queries a list of alarm policies (V2.0). |
tag | DescribeTagKeys | Queries tag keys. |
tag | DescribeTagValues | Queries tag values. |
tag | AttachResourcesTag | Binds tags to resources in batches. |
tag | DetachResourcesTag | Unbinds tags from resources in batches. |
tag | GetResources | Queries a list of resources bound to tags. |
tag | DescribeEffectivePolicy | Queries the effective policy of a target node. |
tcr | DescribeInstances | Queries instance information. |
tcr | DescribeNamespaces | Queries namespace information. |
tcr | DescribeRepositories | Reads image repositories. |
tcr | DescribeRepositoryOwnerPersonal | Queries user-created image repositories. |
tcr | DescribeRepositoryFilterPersonal | Obtains personal image repositories that meet the specified search conditions. |
tcr | DescribeNamespacePersonal | Queries personal namespace information. |
tcr | DescribeInternalEndpoints | Queries the URLs for private network access to an instance. |
vpc | DescribeVpcEx | Queries a list of Virtual Private Cloud (VPC) networks. |
vpc | DescribeSubnetEx | Queries a list of subnets. |
vpc | DescribeNetworkAcls | Queries a list of network ACLs. |
vpc | DescribeSecurityGroupPolicies | Queries security group rules. |
vpc | DescribeSecurityGroupLimits | Queries the security group quota. |