intention

These days, I plan to temporarily transfer my cloud server to someone else. If I send my account directly to someone else, the risk is too high. Discover that you can configure subaccounts under your own main account and set resource access permissions for subaccounts. Now we have made some explorations, mainly to achieve the following functions:

• Subaccounts can only access their own CVM resources
• Subaccounts can view basic information about cloud servers
• Port Opening Rules for Guardwalls that Subaccounts can freely configure

Configuration process

Add Subaccount

1. Personal Avatar - > Access management, then select - > Users - > User list on the page that jumps, and then select New Account
   2. Choose a custom way to add subaccounts here:
   3. Configure the user's account information and basic permission settings:
   
   4. Set up access rights to resources. Custom rights are required here, but you can skip them and associate them after the user has created them.
   Go straight to the next step:
   You can see that the permission information here is empty and you can do it directly.

Custom permission information

1. Access Management->Policy->Custom Policy: Create a new policy
   When you start creating it, it's best to choose Create by Policy Generator, which is convenient:
   3. For some information about the Configuration Generator, you should first choose the service you want to open, because you only want to develop CVM here, so only CVM is selected:

Without configuring operations, set up cloud server resources that we can only access:

Adding permissions means adding another policy generator, which is all you need here. Is for cloud service permissions

Choose the six-paragraph format for custom resources:

• Service: self-generated, no modifications required
• Geography, select the location of the cloud server that subaccounts can access
• Account: also generated by myself. No change required
• Resource prefix: Cloud server, fixed to instance
• Resource: ID of the cloud server, such as ins-XXXX

Note that you can add more than one. If the resource *, then all cloud servers in the region can be accessed

Resource Six-Segment Reference Document

1. Finally, configure the most important operations, which determine what access and operational privileges a subaccount can have. We can search for privileges that we are familiar with, such as those related to security groups:

Because you want your child users to be free to add and delete rules, it's clear that you want to add the rules above

1. Next, you're in the final step of customizing the rules:
   We can give permission to the subaccount we just created.

Leak checking for related permissions

Notice that we only set security groups when we set permissions before, and of course we can set other permissions that we know should be open. However, due to the wide variety of permissions, we are not sure what permissions should be configured for the operations of subaccounts that we restrict.
But Tencent has a dynamic, operation-based permission setting, that is, we log on to subaccounts and then operate. Without the corresponding permissions, there will be pop-up window restrictions. For example, if we access lightweight clouds with subaccounts that can only access cloud servers, there will be:
Notice the green and color sections, which are the key to completing our privileges.

Next we will modify the established strategy:
Select a policy file in json format:

Actions are specific privileges that we configure, and resources are associated with resource information that is involved in privileges. Simply, we add the green part mentioned above to the action and the blue part to the resource.

Note that the generic portion of blue identifies the resource id. So we have to make our own resource id.

We log on to subaccounts early to access and manipulate resources. If there are pop-ups with insufficient prompt permissions, add permissions in json.

Referenced policy josn file

{
    "version": "2.0",
    "statement": [
        {
            "effect": "allow",
            "action": [
                "cvm:DescribeSecurityGroupPolicys",
                "cvm:DescribeUserResources",
                "cvm:CreateSecurityGroupPolicy",
                "cvm:DeleteSecurityGroupPolicy",
                "cvm:ModifyImageAttribute",
                "cvm:ModifySecurityGroupPolicys",
                "cvm:ModifySingleSecurityGroupPolicy",
                "cvm:DescribeInstancesStatus",
                "cvm:DescribeInstances",
                "cvm:DescribeImages",
                "monitor:DescribeBaseMetricsForConsoleFontEnd",
                "cvm:DescribeSecurityGroups",
                "vpc:DescribeVpcEx",
                "vpc:DescribeNetworkInterfaces",
                "cvm:DescribeCbsStorages",
                "cvm:DescribeSecurityGroupLimits",
                "vpc:DescribeAddress",
                "vpc:DescribeService",
                "vpc:DescribeServiceGroups",
                "vpc:DescribeAddressGroups"
            ],
            "resource": [
                "qcs::cvm:ap-shanghai:uin/100022248409:instance/ins-Own ID",
                "qcs::cvm:sh:uin/100022248409:image/img-Own ID",
                "qcs::cvm:sh:uin/100022248409:sg/sg-Own ID",
                "qcs::vpc:sh:uin/100022248409:vpc/vpc-Own ID",
                "qcs::vpc:sh:uin/100022248409:eni/*",
                "qcs:id/0:cvm:sh:uin/100022248409:volume/*",
                "qcs::vpc:sh:uin/100022248409:address/*",
                "qcs::vpc:sh:uin/100022248409:service/*",
                "qcs::vpc:sh:uin/100022248409:serviceGroup/*",
                "qcs::vpc:sh:uin/100022248409:addressGroup/*"
            ]
        }
    ]
}

These IDs are displayed in the information interface of the cloud server:

Reference documentation for permission json files