Grant access to Settings

  • Tutorial
  • 11-min read

This article shows you how to control your user access to Dynatrace settings globally or at an individual settings schema level.

All examples here are based on the Settings 2.0 service. For a complete list of services supporting policy-based authorization, see IAM policy reference.

Who this is for

This is for Dynatrace account administrators who need to grant user access to Dynatrace settings. It also helps new Dynatrace users looking to understand group-based permissions.

What you will learn

In this article, you'll learn how to:

  • Verify custom policies for account administrators.
  • Access IAM features via REST API using an OAuth2 client.
  • Handle read and write permission and allow access to a particular schema.

Before you begin

  • A Dynatrace account with administrative privileges.
  • Set up the required users, federations, and user groups in advance.
Settings 2.0

Unified framework for managing configurations through settings objects defined by Dynatrace-managed schemas.

Settings Schema

A specific configuration structure in Settings 2.0; permissions can be granted per schema for reading or writing.

Policy Administration Point (PAP) REST API

An API used to manage IAM policies, including creating and binding policies to groups.

You can create custom policies for Settings Reader and Setting Writer using the statements below.

  • Settings Reader

    ALLOW settings:objects:read, settings:schemas:read;

  • Settings Writer

    ALLOW settings:objects:read, settings:objects:write, settings:schemas:read;

To verify that you have these policies

  1. Go to Account Management. If you have more than one account, select the account you want to manage.
  2. Go to Identity & access management > Policy management. For more information on available custom policies.

You can access all IAM features via the REST API. Here, we cover the aspects of API request authentication.

The APIs must be accessed using an OAuth2 client.

To generate an OAuth2 client

  1. Go to Account Management and select the account.

  2. Go to Identity & access management > OAuth clients.

    If you don't see this option, you don't have sufficient permission to take this action.

  3. Select Create client.

  4. Enter the email address of the user who owns the client.

  5. optional Enter a description of the new client.

  6. required Select View and manage policies.

  7. Select Create client.

  8. Copy the generated client ID and secret and store them in a safe place.

    You can only access your client secret once upon creation. You can't reveal it afterward.

  9. Once you have a client ID and secret, you can use Dynatrace SSO to request an access token for your client through the client credentials flow. You must include your account UID prefixed with urn:dtaccount in the resource parameter of the request body. For instance:
    urn:dtaccount:12a34567-8901-2bc3-d45e-6f7g8h90123i
    Request a token at https://sso.dynatrace.com/sso/oauth2/token. You can use any OAuth or HTTP client to request the token.

    A sample HTTP request:

    POST /sso/oauth2/token HTTP/1.1
    Host: sso.dynatrace.com
    Content-Type: application/x-www-form-urlencoded
    grant_type=client_credentials&client_id={your client id}&client_secret={your client secret}&scope=iam-policies-management&resource=urn%3Adtaccount%3A{your account UID}

    Now, complete the fields for the /oauth2/token endpoint using data obtained in the previous step as shown below:

    grant_type: client_credentials
    client_id: ${your client id}
    client_secret: ${your client secret}
    scope: iam-policies-management
    resource: urn:dtaccount:${your account UID}

  10. Execute the request.

  11. You can see the required token in the response. This can be used as a Bearer token to authenticate requests to the Policy Administration Point (PAP) REST API.

    The returned token is valid for 5 minutes and can be reused. If you're making multiple calls to the API, you don't have to create a new token for every call.

Example 1: read and write permission

Suppose you have the following teams in your organization:

  • IT team: is responsible for configuring the Dynatrace environment and making sure everything works.
  • Sales team: only needs to read the settings and never modify them.

The IT team needs read and write access, while the sales team needs only read access.

Create two Dynatrace user groups

The policies in the examples presented on this page showcase the mechanics of the policy framework and only give access to the settings service. They enable API access to the settings service, but they don't provide access to the Dynatrace Web UI. To grant access to the Dynatrace platform, follow grant access to Dynatrace guide.

First, create a group named IT with the policies Settings Writer and Settings Reader.

  1. Go to Account Management > Identity & access management > Group management.
  2. Select Create group.
  3. Provide Group name (required) (IT in this example) and a group Description.
  4. optional Add SAML Group Atttribute if SAML is enabled in your account.
  5. Select Create.

After creating the group, use bind policies via the web UI steps to assign the Settings Writer and Settings Reader permission to the group.

Now repeat the above procedure to create a Sales group with read-only access.

  1. Set the group name to Sales.
  2. Bind only the Settings Reader policy to the sales team, as they don't need write access to Dynatrace settings.

Bind policies via the web UI

To create and bound policies to IT and Sales user groups, follow the follwing steps.

  1. Go to Account Management > Identity & access management > Group management.
  2. Find the group you created in the example earlier.
  3. Select the group you created and select > View group.
  4. In the Permissions section, select + Permission.
  5. In the Permission picker page, select the created custom policy.
  6. Add the Scope for your account or environment.
  7. Add Boundaries. Refer to Policy boundaries for more details.
  8. Select Save.
  9. Review the summary on the View group page. If you need to make additional changes, scroll down to Permissions and select the edit link again.

To manage groups further, refer to manage group permissions .

Example 2: allow access to a particular schema

You can add a condition to a policy to achieve more control.

If the custom policies are not granular enough for your needs, you can manage permissions at the setting level.

Assume that you have a particular Settings 2.0 schema, say settings.apm.my-super-secret-schema, the only one you want to keep open for the Sales and IT groups.

You want to allow access to the following:

  • Allow reading of schema settings.apm.my-super-secret-schema
  • Allow reading and writing of objects belonging to the schema settings.apm.my-super-secret-schema

There are two methods to allow access to a schema.

  1. Create a policy via Dynatrace web UI.
  2. Create a policy via REST API.

You can achieve the same with policy boundaries.

Create a policy via Dynatrace web UI

This procedure uses the Dynatrace web UI. To use the REST API, see Create a policy via REST API.

To create a policy:

  1. Go to Account Management > Identity & access management > Policy management.

  2. Select Create policy.

  3. Describe the policy:

    • Name
      Add a relevant name.

    • Description
      Add a useful description.

    • Policy statement
      Copy the following statement to the Policy statements box.

      ALLOW settings:schemas:read WHERE settings:schemaId = "builtin:container.monitoring-rule";
      ALLOW settings:objects:read WHERE settings:schemaId = "builtin:container.monitoring-rule";
      ALLOW settings:objects:write WHERE settings:schemaId = "builtin:container.monitoring-rule";

      Note that since one can use multiple permissions in one statement, it is possible to merge the first two statements from the above into a single one:

      ALLOW settings:schemas:read, settings:objects:read WHERE settings:schemaId = "builtin:container.monitoring-rule";
      ALLOW settings:objects:write WHERE settings:schemaId = "builtin:container.monitoring-rule";

  4. Select Create policy.

The policy is added to your table of policies that you can bind to groups.

Create a policy via REST API

This procedure uses the REST API to perform the same tasks we did in Create a policy via Dynatrace web UI.

To create a policy using the API, we will use the /repo/{level-type}/{level-id}/policies endpoint and use a POST method to add a policy.

Assume that the policy name we want to add is my_policy_name and the description is My policy description. As before, assume that we want this policy to apply only on the environment level for the environment my_tenant_id.

The request body should be the following:

{
   "name":"my_policy_name",
   "description":"My policy description",
   "tags":[


   ],
   "statementQuery": "ALLOW settings:schemas:read WHERE settings:schemaId = \"builtin:container.monitoring-rule\"; ALLOW settings:objects:read WHERE settings:schemaId = \"builtin:container.monitoring-rule\"; ALLOW settings:objects:write WHERE settings:schemaId = \"builtin:container.monitoring-rule\";"
}

Equivalently, using multiple permissions in a single statement, the request body should be the following:

{
   "name":"my_policy_name",
   "description":"My policy description",
   "tags":[


   ],
   "statementQuery": "ALLOW settings:schemas:read, settings:objects:read WHERE settings:schemaId = \"builtin:container.monitoring-rule\"; ALLOW settings:objects:write WHERE settings:schemaId = \"builtin:container.monitoring-rule\";"
}

Enforce the policy

Important: Remember that a policy does not take effect until you bind it to a group. You need to bind this example to the IT and Sales groups. See Bind policies via Dynatrace web UI or Bind policies via REST API for details.

Related tags
Dynatrace Platform