tencent cloud

Defining Application Permission Policies
Last updated: 2025-04-23 14:30:12
Defining Application Permission Policies
Last updated: 2025-04-23 14:30:12

Overview

Cloud applications support software processes in runtime roles calling TencentCloud API. By defining the permission policy for this role, you can finely control the cloud permissions owned by the process, meeting customers' requirements for permission control. Typical scenario:
Verify the status of the software LICENSE.
Access COS buckets in application, with access limited to specified buckets (such as the bucket selected during user installation).
Perform inspections on running resources in application and restart faulty nodes automatically.

Solution Description

Define the permission policy syntax in the package.yaml file, and you can control the application's permission scope.

Declaration Method

Declare the permission policy in the package.yaml file through role.policy. The syntax is consistent with the CAM permission policy. For details, see CAM Permission Policy Syntax Structure. The following is an example:
args:
- name: app_cos
label: select bucket
widget: cos-bucket-select

role:
policy:
version: "2.0"
statement:
# Permission 1: support LICENSE verification
- action:
- cloudapp:VerifyLicense
resource: "*"
effect: allow
# Permission 2: Support restarting CVM under the application instance tag
- action:
- cvm:RebootInstances
resource: "*"
condition:
"for_any_value:string_equal":
"qcs:tag":
- "CloudappId&${var.cloudapp_id}"
effect: "allow"
# Permission 3: Support access to the selected COS storage bucket during installation
- action:
- "cos:*"
resource:
- "qcs::cos:${var.app_cos.region}:uid/${var.app_cos.app_id}:${var.app_cos.bucket}/*"
- "qcs::cos:${var.app_cos.region}:uid/${var.app_cos.app_id}:${var.app_cos.bucket}/"
effect: allow
Note:
Declare permission policies through role.policy following the WYSIWYG principle. All privileges that a runtime role has need to be explicitly declared in package.yaml.

Use Variables in Policy Syntax

Supports the use of two types of variables in policy: system variable and installation parameters. In the above example:
In the example of permission 2, the var.cloudapp_id system variable is used to implement tag authorization.
In the example of permission 3, the var.app_cos installation parameter is used to achieve resource-level authorization.

Upgrade to the New Policy Syntax

Note:
The new permission policy generation solution will have forward compatibility. Permissions originally declared through scopes.cloudAPI will still take effect.
The new permission declaration syntax provides more granular permission control. Strongly recommend upgrading to the new declaration syntax and declare permission policies through role.policy.
The original version declares the permissions of the runtime role through scopes.cloudAPI. An example is as follows:
scopes:
cloudAPI:
- cvm:DescribeInstances
The above declaration grammar after upgrading is as follows:
role:
policy:
version: "2.0"
statement:
- action:
- cvm:DescribeInstances
- cloudapp:VerifyLicense
resource: "*"
effect: allow
Need to pay attention during the upgrade process:
Older versions add the cloudapp:VerifyLicense API to the permission policy by default without the need to explicitly declare it. In the new version, the permissions of the runtime role contain only explicitly declared APIs. You need to explicitly declare role.policy the cloudapp:VerifyLicense, otherwise the application will be unable to integrate with License.
After using the new syntax, the original scopes.cloudAPI field needs to be deleted.

Complete Example

You can refer to the demonstration instructions of Custom Application Permission Policy.

Was this page helpful?
You can also Contact Sales or Submit a Ticket for help.
Yes
No

Feedback