Authentication Granularity Scheme
Last updated:2026-01-13 16:30:11
Application Scenario
If the preset policies do not meet your requirements, you can create custom policies to implement minimum authorization. This topic provides examples of using the Cloud Access Management (CAM) policies to grant users the permissions to view and use specific resources in the Tencent Cloud Elastic MapReduce (EMR) console. In addition, this topic provides instructions on configuring the specific permission policies through the console.
Custom Permission Policy Creation Methods
Creation Method | Authorization Guidance |
Creating custom policies through a policy generator | This method supports selecting services, operations, and defining resources in the policy wizard, automatically generating policy syntax. It can flexibly meet your differentiated permission management needs and is recommended for priority use. For details, see Creating Custom Policies Through a Policy Generator. |
Creating custom policies through tag authorization | This method quickly grants authorization for resources with a category of tag attribute to users or user groups. For details, see Creating Custom Policies Through Tag Authorization. |
Creating custom policies through policy syntax | This method involves users crafting the policy syntax to generate corresponding policies. It offers flexible permission granularity, effectively meeting the demands of users who require a meticulous delineation of permissions. For details, see Creating Custom Policies Through Policy Syntax. |
Authorization Policy Syntax Reference
When creating a custom policy through policy syntax, you need to understand the permission control requirements of your business and the definitions of the EMR policy syntax. The following topic introduces the basic structure of a CAM permission policy and how to define EMR actions, resources, and condition elements in the policy.
Common CAM Policy Syntax
Syntax Example | Description |
{ "version":"2.0", "statement": [ { "effect":"effect", "action":["action"], "resource":["resource"], "condition": {"key":{"value"}} } ] } | version (required): Currently, the only available value is "2.0." |
| statement is used to describe the detailed information of one or more permissions. This element includes the permissions or permission sets of multiple other elements such as effect, action, resource, and condition. A policy has one and only one statement element. 1. effect (required): This element describes whether the statement result is an "allow" or "deny." 2. action (required): This element describes the action to be allowed or denied. An action can be an API (prefixed with name) or a feature set (a set of specific APIs prefixed with actionName). For details, see Actions. 3. resource (required): This element describes the specific authorized data. A resource is described in a 6-segment format. For details, see Resources. 4. condition (optional): This element describes the condition for the policy to take effect. A condition consists of an operator, an action key, and an action value. A condition value may include the time, IP address, tag, and other information. For details, see Conditions. |
Actions
CAM-Enabled EMR APIs
In a CAM policy statement, you can specify any API action from the EMR APIs that support CAM. For details, see CAM-Enabled EMR APIs.
Action Setting Examples
Scenario | Example |
Specifying multiple actions in a single statement | Use APIs prefixed with emr: and separate them with commas, as follows: "action":["emr:action1","emr:action2"] |
Specifying multiple actions using a wildcard | Specify all actions whose names start with the word "Describe," as follows: "action":["emr:Describe*"] |
Specifying all actions in EMR | Use the * wildcard, as follows: "action":["emr:*"] |
Resources
EMR Authorizable Resource Types
EMR resource types that can be authorized in CAM and their corresponding resource description methods are as follows:
Resource Type | Resource Description Method in Authorization Policies |
Elastic MapReduce instance | qcs::emr:${region}:uin/${uin}:emr-instance/${emrInstanceId} |
Elastic MapReduce node | qcs::emr:${region}:uin/${uin}:emr-vm/${emrResourceId} |
Elastic MapReduce reservation package | qcs::emr:${region}:uin/${uin}:emr-reserve/${emrReserveId} |
${region}: Describes region information. For more information on the region naming method, see Region List. If this field is empty, it indicates all regions. For example, North China (Beijing) is ap-beijing.${uin}: Account ID of the root account. For example: uin/12345678.${emrInstanceId}, ${emrResourceId}, ${emrReserveId}: Specific resource IDs, which can be viewed in the corresponding product console. If the value is *, it indicates all resources of this type. For example, emr-instance/*.EMR APIs support 2 authorization granularity levels: operation level and resource level.
Resource-level API: This type of API supports the authorization of a specific resource. For the resource types that can be authorized with resource-level APIs, see CAM-Enabled EMR APIs.
Operation-level API: This type of API does not support the authorization of a specific resource. If the policy syntax restricts a specific resource during authorization, CAM will determine that this API is not within the scope of authorization, and deem it as unauthorized. Therefore, the resource element of the policy statement during authorization of the operation-level API should be specified as *.
Resource Setting Example
Scenario | Example |
Specifying the use of specific cluster resources | Specify using the cluster ID (emr-12345) of the Beijing region, as follows: "resource":[ "qcs::emr:ap-beijing:uin/12345678:emr-instance/emr-12345"] |
Specifying the use of all cluster resources under the root account | Use the * wildcard to indicate all resources, as follows: "resource":[ "qcs::emr:ap-beijing:uin/12345678:emr-instance/*"] |
Specifying all resources, or a specific API action not supporting resource-level permissions | Use the * wildcard in the resource element, as follows: "resource": "*" |
Specifying multiple resources simultaneously in a single instruction | Specify 2 resources and separate them with commas, as follows: "resource":["resource1","resource2"] |
Conditions
EMR has not defined product-level condition keywords. To view common condition keywords applicable to all cloud products, see Overview of Effective Conditions.
Example
Example Scenario | Supported Policy Creation Methods |
(This is a preset policy, and does not need to be customized.) | |
Creating through a policy generator, and creating through policy syntax | |
Creating through policy syntax, and tag-based authorization | |
Creating through a policy generator, and creating through policy syntax | |
Creating through a policy generator, and creating through policy syntax | |
Creating through policy syntax, and tag-based authorization |
Example 1: Granting a User the Read-only Permission for EMR
If you want to grant a sub-account user the query permission for EMR but not the creation and deletion permissions, you can grant the preset policy QcloudEMRReadOnlyAccess to the user. For details, see Purchasing and Managing EMR Clusters.
Example 2: Granting a User the Permission to View EMR Clusters
The following topic describes how to grant a sub-account user the basic permission to view EMR clusters. You can associate the following policy with the user. The specific steps are as follows:
1. Create a custom policy.
Enter the CAM Policy page and click Create Custom Policy.
Select a policy creation method:
Select Creating through a policy generator.
On the Select Service page of the Visual Policy Generator, select Elastic MapReduce (EMR) and add the following information.
Effect (required): Select Allow.
Service (required): Select Elastic MapReduce (EMR).
Action (required): Select Add Custom Action, then add Inquiry*, Check*, and Describe* in sequence.
Resource (required): Select all resources.
Click Add Permission, select a tag, and add the following information.
Effect (required): Select Allow.
Service (required): Select a tag.
Action (required): Unfold All Actions, then select the GetTags, DescribeResourceTagsByResourceIds, GetTagKeys, and GetTagValues APIs in sequence.
Resource (required): Select all resources.
Click Add Permission, select Finance, and add the following information.
Effect (required): Select Allow.
Service (required): Select Finance.
Action (required): Select All Actions.
Resource (required): Select all resources.
After editing the permission policy statement, click Next to enter the Basic Information and Associate User/User Group/Role page.
On the Associate User/User Group/Role page, create a custom policy named Operator-emr-basic. You can associate users, user groups, or roles for quick authorization at the same time.
Click Completed to finish creating a custom policy through the policy generator.
Select Creating through policy syntax.
When selecting a policy template, select Blank Template and click Next.
Create a custom policy named Operator-emr-basic, which can be self-defined as needed. Clear the existing content in the policy, then configure as follows. Save it after creation.
{"statement": [{"action": ["tag:GetTags","finance:*","tag:DescribeResourceTagsByResourceIds","tag:GetTagKeys","tag:GetTagValues","emr:Inquir*","emr:Check*","emr:Describe*"],"effect": "allow","resource": ["*"]}],"version": "2.0"}
Note:
During the evolution of EMR, APIs will be adjusted appropriately according to the situation. An operation error may occur when new APIs are subsequently added. In case of permission error, you can submit a ticket or contact us.
This policy includes finance and tag permissions, which can be added on demand, to support users in creating clusters, using tags, and performing tag authorization.
2. Authorize and authenticate a sub-account user.
On the user list page, find the target sub-user and click the Authorize button on the right. For detailed operations on creating a sub-user, see Creating a Sub-user.
Select the custom policy Operator-emr-basic and authorize it to the sub-account user. For details, see Authorization Management.
Log in as a sub-user for authentication. Users can create and view EMR clusters.
Example 3: Granting a User the Permission to Force Tag Binding When Resources are Created
The following topic describes how to require a sub-account user to bind the specified tag key-value pair in the permission policy when a cluster is created. If the sub-account user does not bind the tag or binds other tags, the cluster creation will fail. You can first grant a user the permission to view EMR clusters, then associate the following policy with the user. The specific steps are as follows:
1. Create a custom policy.
Enter the CAM Policy page and click Create Custom Policy.
Select a policy creation method:
Select Creating through policy syntax.
When selecting a policy template, select Blank Template and click Next.
Create a custom policy named Operator-emr-request_tag, which can be self-defined as needed. Clear the existing content in the policy, and configure and save the policy as follows.
{"statement": [{"action": ["emr:CreateInstance"],"condition": {"for_any_value:string_equal": {"qcs:request_tag": ["App&Dev"]}},"effect": "allow","resource": ["*"]}],"version": "2.0"}
Select Tag-based Authorization.
On the Select Service page of the Visual Policy Generator, select Elastic MapReduce (EMR) and add the following information.
Effect (required): Select Allow.
Service (required): Select Elastic MapReduce (EMR).
Action (required): Unfold All Actions, then select the CreateInstance API.
In the Select Tag section, select the tag key (App) and the tag value (Dev).
Select request_tag as the condition key and select OR (for_any_value) as the condition operator.
Select No, indicating not to grant the API that does not support tags the permission of "resource": "*".
After editing the permission policy statement, click Next to enter the Basic Information and Associate User/User Group/Role page.
On the Associate User/User Group/Role page, create a custom policy named Operator-emr-request_tag. You can associate users, user groups, or roles for quick authorization at the same time.
Click Completed to finish creating a custom policy through the policy generator.
2. Authorize and authenticate a sub-account user.
On the user list page, find the target sub-user and click the Authorize button on the right. For detailed operations on creating a sub-user, see Creating a Sub-user.
Select the custom policies Operator-emr-basic and Operator-emr-request_tag and authorize them to the sub-account user. For details, see Authorization Management.
Log in as a sub-user for authentication and attempt to purchase an EMR cluster without setting any tags and without setting the corresponding tag (App & Dev).
When no tags are set, a "no operation permissions" prompt appears.
When the corresponding tag (App & Dev) is not set, a "no operation permissions" prompt appears.
When the corresponding tag (App & Dev) is set, an "operation permissions granted" prompt appears.
Example 4: Granting a User the Specific Operation Permissions for EMR
The following topic describes how to grant a sub-account user the EMR node scale-out permission. You can first grant a user the permission to view EMR clusters, then associate the following policy with the user. The specific steps are as follows:
1. Create a custom policy.
Enter the CAM Policy page and click Create Custom Policy.
Select a policy creation method:
Select Creating through a policy generator.
On the Select Service page of the Visual Policy Generator, select Elastic MapReduce (EMR) and add the following information.
Effect (required): Select Allow.
Service (required): Select Elastic MapReduce (EMR).
Action (required): Unfold All Actions, then select the ScaleOutInstance API.
Resource (required): Select all resources.
After editing the permission policy statement, click Next to enter the Basic Information and Associate User/User Group/Role page.
On the Associate User/User Group/Role page, create a custom policy named Operator-emr-ScaleOutInstance. You can associate users, user groups, or roles for quick authorization at the same time.
Click Completed to finish creating a custom policy through the policy generator.
Select Creating through policy syntax.
When selecting a policy template, select Blank Template and click Next.
Create a custom policy named Operator-emr-ScaleOutInstance, which can be self-defined as needed. Clear the existing content in the policy, and configure and save the policy as follows.
{"statement": [{"action": ["emr:ScaleOutInstance"],"effect": "allow","resource": ["*"]}],"version": "2.0"}
2. Authorize and authenticate a sub-account user.
On the user list page, find the target sub-user and click the Authorize button on the right. For detailed operations on creating a sub-user, see Creating a Sub-user.
Select the custom policies Operator-emr-basic and Operator-emr-ScaleOutInstance and authorize them to the sub-account user. For details, see Authorization Management.
Log in as a sub-user for authentication and attempt to scale out EMR nodes. The scale-out is successful.
Example 5: Granting a User the Operation Permissions for Specified Resources
The following topic describes how to grant a sub-account user the scale-in permission for specified nodes. You can first grant a user the permission to view EMR clusters, then associate the following policy with the user. The specific steps are as follows:
1. Create a custom policy.
Enter the CAM Policy page and click Create Custom Policy.
Select a policy creation method:
Select Creating through a policy generator.
On the Select Service page of the Visual Policy Generator, select Elastic MapReduce (EMR) and add the following information.
Effect (required): Select Allow.
Service (required): Select Elastic MapReduce (EMR).
Action (required): Unfold All Actions, then select the TerminateNodes API.
Resource (required): Select a Specific Resource. For example, add a 6-segment resource description to emr-instance and enter
emr-12345 for the resource. Add a 6-segment resource description to emr-vm and enter emr-vm-12345 for the resource.After editing the permission policy statement, click Next to enter the Basic Information and Associate User/User Group/Role page.
On the Associate User/User Group/Role page, create a custom policy named Operator-emr-resource-instance. You can associate users, user groups, or roles for quick authorization at the same time.
Click Completed to finish creating a custom policy through the policy generator.
Select Creating through policy syntax.
When selecting a policy template, select Blank Template and click Next.
Create a custom policy named Operator-emr-resource-instance, which can be self-defined as needed. Clear the existing content in the policy, and configure and save the policy as follows.
{"statement": [{"action": ["emr:TerminateNodes"],"effect": "allow","resource": ["qcs::emr::uin/12345678:emr-instance/emr-12345","qcs::emr::uin/12345678:emr-vm/emr-vm-12345"]}],"version": "2.0"}
2. Authorize and authenticate a sub-account user.
On the user list page, find the target sub-user and click the Authorize button on the right. For detailed operations on creating a sub-user, see Creating a Sub-user.
Select the custom policies Operator-emr-basic and Operator-emr-resource-instance and authorize them to the sub-account user. For details, see Authorization Management.
Log in as a sub-user for authentication and try scaling in node A (Node ID: emr-vm-12345) and node B, respectively.
When you attempt to scale in node A, the scale-in is successful.
When you try to scale in node B, a "no operation permissions" prompt appears.
Example 6: Granting a User the Tag-based Operation Permissions
The following topic describes how to grant a sub-account user the permission to modify node configurations based on tags. You can first grant a user the permission to view EMR clusters, then associate the following policy with the user. The specific steps are as follows:
1. Create a tag and add the tag for the cluster.
Enter the Tag List page and click Create Tag.
Note:
Here and in the subsequent process, the tag (App) is used as an example.
Enter the tag key (App) and tag value (Dev) and click OK. The tag creation is successful.
On the Cluster List page, select the cluster to be tagged. Click More Operations at the top and then click Edit Tag.
On the Edit Tag page, select the previously created tag (App) and click OK.
2. Create a custom policy.
Enter the CAM Policy page and click Create Custom Policy.
Select Creating through policy syntax.
Select a policy creation method:
When selecting a policy template, select Blank Template and click Next.
Create a custom policy named Operator-emr-resource_tag, which can be self-defined as needed. Clear the existing content in the policy, and configure and save the policy as follows.
{"statement": [{"action": ["emr:ModifyResource"],"condition": {"for_any_value:string_equal": {"qcs:resource_tag": ["App&Dev"]}},"effect": "allow","resource": ["*"]}],"version": "2.0"}
Select Tag-based authorization.
On the Select Service page of the Visual Policy Generator, select Elastic MapReduce (emr) and add the following information.
Effect (required): Select Allow.
Service (required): Select Elastic MapReduce (emr).
Action (required): Unfold All Actions, then select the ModifyResource API.
In the Select Tag section, select the tag key (App) and the tag value (Dev).
Select resource_tag as the condition key and select OR (for_any_value) as the condition operator.
Select Yes, indicating to grant the API that does not support tags the permission of "resource": "*".
After editing the permission policy statement, click Next to enter the Basic Information and Associate User/User Group/Role page.
On the Associate User/User Group/Role page, create a custom policy named Operator-emr-resource_tag. You can associate users, user groups, or roles for quick authorization at the same time.
Click Completed to finish creating a custom policy through the policy generator.
3. Authorize and authenticate a sub-account user.
On the user list page, find the target sub-user and click the Authorize button on the right. For detailed operations on creating a sub-user, see Creating a Sub-user.
Select the custom policies Operator-emr-basic and Operator-emr-resource_tag and authorize them to the sub-account user. For details, see Authorization Management.
Log in as a sub-user for authentication and try to adjust configuration of the nodes with the tag (App & Dev) and nodes without the tag (App & Dev), respectively.
When you perform operations on nodes with the tag (App & Dev), the configuration adjustment is successful.
When you perform operations on nodes without the tag (App & Dev), a "no operation permissions" prompt appears.
Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No
Feedback