Using IAM Roles or Policies to Grant Access to DNS

Prerequisites

Before granting permissions to user groups, learn about system-defined permissions in Role/Policy-based Authorization. To grant permissions for other services, learn about all system-defined policies/roles supported by IAM.

Process Flow

Figure 1 Process of granting DNS permissions using role/policy-based authorization

1. On the IAM console, create a user group and grant it permissions.

   Create a user group on the IAM console and assign the DNS DNS ReadOnlyAccess permissions to the group.

2. On the IAM console, create an IAM user and add the user to the group.
3. Log in as the IAM user and verify permissions.

   In the authorized region, perform the following operations:

   • Choose Service List > Domain Name Service. On the DNS console, choose Overview > Private Zones. On the displayed page, click Create Private Zone. If the private zone cannot be created, the DNS ReadOnlyAccess policy has already taken effect.
   • Choose another service from Service List. If a message appears, indicating that you have insufficient permissions to access the service, the DNS ReadOnlyAccess policy is in effect.

Example Custom Policies

You can create custom policies to supplement the system-defined policies of DNS. For details about actions supported in custom policies, see "Actions Supported by Role/Policy-based Authorization" in the Domain Name Service API Reference.

To create a custom policy, choose either visual editor or JSON.

• Visual editor: Select cloud services, actions, resources, and request conditions. This does not require knowledge of policy syntax.
• JSON: Create a JSON policy or edit an existing one.

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

• Example 1: Grant permissions to create zones.

  {
      "Version": "1.1",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "dns:zone:create"
              ]
          }
      ]
  }

• Example 2: Grant permissions to deny zone deletion.

  A policy with only "Deny" permissions must be used together with other policies. If the permissions granted to an IAM user contain both "Allow" and "Deny", the "Deny" permissions take precedence over the "Allow" permissions.

  Assume that you want to grant the permissions of the DNS FullAccess policy to a user but want to prevent them from deleting zones. You can create a custom policy for denying zone deletion, and attach this policy together with the DNS FullAccess policy to the user. As an explicit deny in any policy overrides any allows, the user can perform all operations on zones excepting deleting them. Example policy denying zone deletion:

  {
      "Version": "1.1",
      "Statement": [
          {
              "Effect": "Deny",
              "Action": [
                  "dns:zone:delete"
              ]
          }
      ]
  }

• Example 3: Create a custom policy containing multiple actions.

  A custom policy can contain the actions of one or multiple services that are of the same type (global or project-level). Example policy containing multiple actions:

  {
      "Version": "1.1",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "dns:recordset:create",
                  "dns:zone:create"
              ]
          },
          {
              "Effect": "Deny",
              "Action": [
                  "dns:zone:delete",
                  "dns:recordset:delete"
              ]
          },
          {
              "Effect": "Allow",
              "Action": [
                  "vpc:vpcs:list",
                  "vpc:vpcs:get"
              ]
          }
      ]