Permissions Management

If you need to assign different permissions to employees in your enterprise to access SecMaster resources you buy on Huawei Cloud, Identity and Access Management (IAM) is a good choice for fine-grained permissions management. IAM provides identity authentication, permissions management, and access control, helping you secure access to your Huawei Cloud resources. If your account works good for you and you do not need an IAM account to manage user permissions, then you may skip over this chapter.

IAM is free of charge. You pay only for the resources in your account.

With IAM, you can control the access to Huawei Cloud resources through authorization. For example, some developers in your enterprise need to use SecMaster but you do not want them to have permissions to high-risk operations such as deleting SecMaster. To achieve such purpose, you can use IAM to grant them only the permissions to use SecMaster, but not delete SecMaster. With IAM, you can control their usage of SecMaster resources.

There are two types of IAM authorization: role and policy authorization and identity policy authorization.

The differences and relationships between the two authorization models are as follows:

**Table 1** Differences between the two types of authorization
Name	Relationship	Permission	Authorization Method	Scenario
Policies/Roles	User-permission-authorization scope	System-defined roles System-defined policies Custom policies	Granting a role or policy to a subject	To authorize a user, you need to add it to a user group first and then specify the scope of authorization. It is hard to provide fine-grained permissions control using authorization by user groups and a limited number of condition keys. This method is suitable for small- and medium-sized enterprises.
Identity Policies	User-Policy	System-defined policy Custom policies	Granting an identity policy to a subject Attaching identity policies to principals	You can authorize a user by attaching an identity policy to it. User-specific authorization and a variety of key conditions allow for more fine-grained permissions control. However, this model can be hard to set up. It requires a certain amount of expertise and is suitable for medium- and large-sized enterprises.

For example, if you want to grant an IAM user the permissions to create ECSs in CN North-Beijing4 and OBS buckets in CN South-Guangzhou, you need to use the administrator role to create two custom policies and assign them to the IAM user. With identity policy-based authorization, the administrator only needs to create one custom identity policy and configure the condition key g:RequestedRegion for the policy, and then attach the policy to the users or grant the users the access permissions to the specified regions. Identity policy-based authorization is more flexible than role/policy-based authorization.

Policies and actions in the two authorization models are not interoperable. You are advised to use the identity policy-based authorization model. Role and Policy-based Permissions Management and Identity Policy-based Permissions Management describe the system permissions of the two models.

For details about IAM, see IAM Service Overview.

Role and Policy-based Permissions Management

SecMaster supports role/policy-based authorization. By default, new IAM users do not have permissions assigned. You need to add a user to one or more groups, and attach permissions policies or roles to these groups. Users inherit permissions from the groups to which they are added and can perform specified operations on cloud services.

SecMaster is a project-level service deployed and accessed in specific physical regions. When you set Scope to Region-specific projects and select the specified projects (for example, ap-southeast-2) in the specified regions (for example, AP-Bangkok), the users only have permissions for resources in the selected projects. If you set Scope to All resources, the users have permissions for resources in all region-specific projects. To access SecMaster, the users need to switch to a region where they have been authorized to use cloud services.

Table 2 lists all SecMaster system permissions. System policies for role/policy-based authorization are independent from the ones for identity policy-based authorization.

**Table 2** System-defined permissions supported by SecMaster
Role/Policy Name	Description	Type	Dependency
SecMaster FullAccess	All permissions of SecMaster.	System-defined policy	None
SecMaster ReadOnly	SecMaster read-only permission. Users granted with these permissions can only view SecMaster data but cannot configure SecMaster.	System-defined policy	None

Table 3 describes the common operations supported by each system-defined permission of SecMaster. Select the permissions as needed.

**Table 3** Common operations for each system-defined policy or role of SecMaster
Operation	SecMaster FullAccess	SecMaster ReadOnly
Creating a pay-per-use order	√	x
Creating a yearly/monthly order	√	x
Viewing the subscribed version	√	x
Viewing indicator results	√	√
Creating agencies	√	x
Importing resources	√	x
Viewing a report	√	√
Exporting emergent vulnerabilities	√	x
Creating data spaces	√	x
Creating pipelines	√	x
Querying data	√	√
Analyzing execution	√	x
Creating search criteria	√	x
Creating an alarm model	√	x
Enabling an alarm model	√	x
Querying an alarm template	√	√
Creating a playbook	√	x
Review playbooks	√	x
Creating a playbook version	√	x
Creating playbook version rules	√	x
Creating playbook version actions	√	x
Creating a workflow	√	x
Creating a workflow version	√	x
Reviewing a workflow version	√	x
Querying the asset connection list	√	√
Creating an asset connection	√	x
Creating a workspace	√	x
Querying the to-do list	√	√
Binding intelligence types to layouts	√	x
Querying alert details	√	√
Converting alerts into incidents	√	x
Querying alarm types	√	√
Binding alarm types to layouts	√	x
Obtaining incident details	√	√
Binding incident types to layouts	√	x
Obtaining vulnerability group details	√	√
Exporting the vulnerability group list	√	x
Binding vulnerability types to layouts	√	x

Roles or Policies Required for Operations on the SecMaster Console

If you grant the SecMaster FullAccess permission of Region-specific projects to an IAM user, you still need to grant the IAM user the permissions to create agencies and configure agency policies when authorizing SecMaster on its console. The details are as follows.

**Table 4** Roles or policies required for operations on the SecMaster console
Console Function	Dependent Services	Policy/Role Required
Service authorization	Identity and Access Management (IAM)	If an IAM user has been assigned the SecMaster FullAccess permission of Region-specific projects, you need to grant the permissions for creating agencies and configuring agency policies to the IAM user. For details, see Granting Permissions to an IAM User.

Identity Policy-based Permissions Management

SecMaster supports identity policy-based authorization. Table 5 lists all the system-defined identity policies for SecMaster. System-defined identity policies are independent from system policies in role/policy-based authorization.

**Table 5** System-defined identity policies for SecMaster
Policy Name	Description	Role Type
SecMasterFullAccess	All permissions of SecMaster.	System-defined policy
SecMasterReadOnly	SecMaster read-only permission. Users granted with these permissions can only view SecMaster data but cannot configure SecMaster.	System-defined policy

Table 6 lists the common operations supported by system-defined identity policies for SecMaster.

**Table 6** Common operations supported by each system-defined policy
Operation	SecMasterFullAccess	SecMasterReadOnly
Creating a pay-per-use order	√	x
Creating a yearly/monthly order	√	x
Viewing the subscribed version	√	x
Viewing indicator results	√	√
Creating agencies	√	x
Importing resources	√	x
Viewing reports	√	√
Exporting emergent vulnerabilities	√	x
Creating data spaces	√	x
Creating pipelines	√	x
Querying data	√	√
Analyzing execution	√	x
Creating search criteria	√	x
Creating an alarm model	√	x
Enabling an alarm model	√	x
Querying an alarm template	√	√
Creating a playbook	√	x
Review playbooks	√	x
Creating a playbook version	√	x
Creating playbook version rules	√	x
Creating playbook version actions	√	x
Creating a workflow	√	x
Creating a workflow version	√	x
Reviewing a workflow version	√	x
Querying the asset connection list	√	√
Creating an asset connection	√	x
Creating a workspace	√	x
Querying the to-do list	√	√
Binding intelligence types to layouts	√	x
Querying alert details	√	√
Converting alerts into incidents	√	x
Querying alarm types	√	√
Binding alarm types to layouts	√	x
Obtaining incident details	√	√
Binding incident types to layouts	√	x
Obtaining vulnerability group details	√	√
Exporting the vulnerability group list	√	x
Binding vulnerability types to layouts	√	x

Identity Policies Required for Operations on the SecMaster Console

**Table 7** Roles or policies required for operations on the SecMaster console
Console Function	Dependent Services	Role/Policy Required
Service authorization	Identity and Access Management (IAM)	If an IAM user has been assigned the SecMaster FullAccess permission of Region-specific projects, you need to grant the permissions for creating agencies and configuring agency policies to the IAM user. For details, see Granting Permissions to an IAM User.

Granting Permissions to an IAM User

SecMaster is a project-level service deployed and accessed in specific physical regions. So, during authorization, you need to select Region-specific projects for Scope first. Then, you can specify specific projects for which you want the permission to work.

After SecMaster FullAccess is granted to an IAM user for a region-level project, you need to grant global action permissions to the IAM user because SecMaster depends on other cloud service resources. The permissions to be added are as follows:

    
     
       
       
         {
    "Version": "5.0",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:roles:listRoles",
                "iam:agencies:listAgencies",
                "iam:permissions:checkRoleForAgencyOnDomain",
                "iam:permissions:checkRoleForAgencyOnProject",
                "iam:permissions:checkRoleForAgency",
                "iam:agencies:createAgency",
                "iam:permissions:grantRoleToAgencyOnDomain",
                "iam:permissions:grantRoleToAgencyOnProject",
                "iam:permissions:grantRoleToAgency"
            ]
        }
    ]
}

        

      

    
   

iam:permissions:grantRoleToAgencyOnDomain, iam:permissions:grantRoleToAgency, iam:permissions:grantRoleToAgencyOnProject, and iam:agencies:createAgency are permissions required for using SecMaster. You need to grant such permissions when you authorize SecMaster. They are not mandatory for IAM users. Configure them as required. The authorization details are as follows:

Unauthorized: Only the account used to create the IAM user can authorize SecMaster. If an IAM user attempts to authorize SecMaster, an error message will be displayed.
Authorized: Both IAM users and the account used to create them can authorize SecMaster.