Using IAM Roles or Policies to Grant Access to SecMaster

Prerequisites

Before assigning permissions to a user group, you need to understand the SecMaster permissions. For details, see Role and Policy Permission Management. For details about the permissions of other services, see System Permissions.

Permission Granting Process

Figure 1 Process for granting SecMaster permissions

1. Creating a User Group and Assigning Permissions to It

   Create a user group on the IAM console, and assign the SecMaster ReadOnly permission to the group.

2. Creating a User and Adding the User to a User Group

   Create a user on the IAM console and add the user to the group created in 1.

3. Logging In as an IAM User and Verifying the Permissions

   Log in to the SecMaster console as the created user, and verify that the user only has read permissions for SecMaster.

   • Choose Service List > SecMaster. Then click Buy SecMaster. If you cannot buy SecMaster (assuming that the current permissions include only SecMaster ReadOnly), the SecMaster ReadOnly permission has already taken effect.
   • Choose any other service in the Service List. (The current policy contains only SecMaster ReadOnly.) If a message appears indicating insufficient permissions, the SecMaster ReadOnly policy has already taken effect.

Example Custom Policies

Custom policies can be created to supplement the system-defined policies of SecMaster. For the actions supported for custom policies, see Actions Supported by Policy-based Authorization.

Currently, Huawei Cloud allows you to create custom policies in either of the following ways:

• Visual editor: Select cloud services, actions, resources, and request conditions. This does not require knowledge of policy syntax.
• JSON: Edit JSON policies from scratch or based on an existing policy.

For details, see Creating a Custom Policy. The following provides examples of common SecMaster custom policies.

• Example 1: Authorizing a user to create and delete workspaces

  1 2 3 4 5 6 7 8 9 10 11 12

  { "Version": "1.1", "Statement": [ { "Effect": "Allow", "Action": [ "secmaster:workspace:delete", "secmaster:workspace:create" ] } ] }

• Example 2: Denying workspace deletion

  A deny policy must be used together with other policies. If the policies assigned to a user contain both Allow and Deny actions, the Deny actions take precedence over the Allow actions.

  If you grant the SecMaster FullAccess system policy to a user but do not want the user to have the workspace deletion permission defined in the policy, you can create a custom policy that denies workspace deletion and grant both the custom policy and the SecMaster FullAccess policy to the user. According to the "Deny first" principle, users can perform all operations on SecMaster except deleting workspaces. The following is an example of a deny policy:

  1 2 3 4 5 6 7 8 9 10 11 12 13

  { "Version": "1.1", "Statement": [ { "Effect": "Deny", "Action": [ "secmaster:workspace:delete", "secmaster:workspace:create", "secmaster:dataspace:delete" ] } ] }

• Example 3: Defining permissions for multiple services in a policy

  A custom policy can contain the actions of multiple services that are of the global or project-level type. The following is an example policy containing actions of multiple services:

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

  { "Version": "1.1", "Statement": [ { "Effect": "Allow", "Action": [ "secmaster:playbook:update", "secmaster:playbook:updateVersion", "secmaster:workspace:delete", "secmaster:workspace:create", "secmaster:dataspace:delete", "secmaster:playbook:approve", "secmaster:playbook:createVersion" ] } ] }

SecMaster Resources

Resources are objects in services. In SecMaster, resources include alerts, playbooks, workflows, and indicators. You can select specific resources by specifying resource paths when creating custom policies.

SecMaster Request Conditions

Request conditions are useful in determining when a custom policy is in effect. A request condition consists of condition keys and operators. Condition keys are either global or service-specific and are used in the Condition element of a policy statement. Global condition keys (starting with g:) are available for operations of all services, while service-specific condition keys (starting with a service name such as secmaster:) are available only for operations of specific services. An operator must be used together with a condition key to form a complete condition statement.

secmaster:TargetRegion is a service-level condition key supported by SecMaster.