• Home
  • Manage
  • Access control
  • User management and SSO
  • Manage user groups and permissions
  • Manage policies and groups with Dynatrace IAM

Manage policies and groups with Dynatrace IAM

Use Dynatrace identity and access management (IAM) to manage user access to Dynatrace features.

Overview

With the IAM framework, you can define policies that clearly specify whether an action in Dynatrace is allowed. When policies are bound to user groups, they describe an access pattern for the group that is enforced at runtime. This gives you much more fine-grained control over how your users interact with Dynatrace.

How to configure IAM

You can configure IAM through the Dynatrace web UI or REST API.

  • To manage Dynatrace IAM policies, see Manage IAM policies
  • To manage group permissions with IAM policies, see Manage group permissions with IAM policies
  • To list all REST API calls, see Dynatrace Account Management API 1.0
  • To see examples of Dynatrace web UI and REST API configuration procedures, see Get started with IAM. There are also several examples on the Manage IAM policies and IAM policy statement syntax and examples pages.
  • To learn more about how to write policies, see IAM policies syntax
  • To list all supported values for each Dynatrace IAM service, permission, and condition, see IAM services reference

FAQ

How is IAM different?

Before IAM, Dynatrace offered (and still offers!) access control based on roles, where each role had a fixed set of permissions, and each user or user group could be assigned one or more roles.

The new IAM framework offers additional control over access by enabling you to create your own access policies based on a fine-grained set of permissions and conditions that can be enforced per service, not per role. You can even set policies for single resources within a service.

What is the value of IAM to me?

The Dynatrace IAM framework gives you more control over permissions within the system.

  • Administration of permissions is easier and more scalable. You can manage IAM through the Dynatrace web UI or API.
  • You are able to more flexibly control who has access to specific parts of the system and whether they can change settings or only view them. Some employees (such as admins) may need to have the ability to do almost everything in Dynatrace, while others may need to see only specific hosts, settings, or synthetic monitors.
  • Instead of permissions that give all-or-nothing access, IAM granularity enables you to grant users exactly the right amount of access.
How does IAM improve data security?

IAM is designed first and foremost to make Dynatrace safer.

  • IAM enables admins to more selectively grant permissions based strictly on necessity following the principle of least privilege (PoLP).
  • IAM enables you to realize access patterns that were not possible before. For instance, you can allow a user access to a single resource (a single setting or schema), regardless of user roles. Before IAM, you would have to assign the user a role for which such fine-grained control is not possible.
  • IAM helps to make Dynatrace permissions easier to understand, which means admins can more reliably administer permissions.
Who can manage IAM policies?

Only admin users can manage IAM policies.

  • SaaS: users with account permission Manage users
  • Managed: users with group with Cluster administrator permission selected
How can I automate IAM?
  • SaaS

    IAM exposes an API for policies and its bindings management. The IAM API specification is available at https://api.dynatrace.com/spec/ in the Policy Management section.

    To be able to access the API within a customer account, there must be an OAuth client generated in BAS (MyWeb): https://account.dynatrace.com/my/enterprise-api.

    • Make sure that the OAuth client is generated with checkbox Allow IAM policy configuration for environments. selected.
    • When obtaining the token according to the instruction on the https://account.dynatrace.com/my/enterprise-api page, be sure to request scope iam-policies-management from the list of scopes.
  • Managed

    The IAM API in a Dynatrace Managed cluster is exposed under the Cluster v2 API.
    To review the specification

    1. In the user menu, select Cluster API v2.
    2. Scroll down to the IAM sections.

    To gain access to the IAM cluster API, you need to generate an API token in the Cluster Management Console.

    1. In the CMC, select Settings > API tokens.
    2. In the Cluster tokens section, select Generate token.
    3. Enter a Token name, select Service Provider API, and then Save your token.
What are the differences between RBAC permissions (old) and ABAC policies (new)?
  • Role-based access control (RBAC) determines a user's access based on their role (which is determined by characteristics such as department, location, seniority, and duties).

    Before introducing IAM, Dynatrace offered (and still offers!) role-based access control, where each role had a fixed set of permissions, and each user or user group could be assigned one or more roles.

  • Attribute-based access control (ABAC) determines a user's access based on their role, the type of resource being accessed (such as file type, owner, and sensitivity), and the environment (location, date, and time). This enables higher granularity in controlling access, but it also requires a little more knowledge.

    The new IAM framework is ABAC: you control access by creating access policies based on a fine-grained set of permissions and conditions that can be enforced per service, not per role. You can even set policies for a single resource within a service.

For examples of usage, see Get started with IAM.

Why can't I create a policy via the API?

Make sure your token gives you sufficient access.

  • SaaS: To manage policies via API, your token has to contain the iam-policies-management access scope.
  • Managed: Your token requires the Service Provider API access scope.
In which cluster version is IAM enabled by default?

Dynatrace version 1.226+

What is the difference between global and cluster/account policies?

Each IAM policy has a level that determines its scope:

  • global: Global policies are predefined and managed by Dynatrace, and they apply to all accounts and environments. They cannot be edited.
  • account: Account policies apply to all environments under that account (customer). Use them to set your company-wide policies.
    • In a Dynatrace Managed deployment, this is cluster.
  • environment: Environment policies apply only to a single customer environment.
When does a policy change take effect?

SaaS:

  • Most changes should be visible immediately; a delay of a few seconds is possible.
  • Changes in user-group assignments require sign-out and sign-in.

Managed:

  • By default, the refresh interval is set to 120 seconds (two minutes).
  • Changes in user-group assignments require sign-out and sign-in.
Why can't I create another policy?

There is an internal limitation of 200 policies. You may have reached the limit.

Where can I manage policies in the web UI?

SaaS

In Dynatrace SaaS, only admin users can manage IAM policies (users with account permission Manage users).

If you have access to IAM policy management

  1. In the user menu, select Account settings.
  2. Go to Identity management > Policy management.
  3. Add, view, edit, and delete policies as needed. For details, see Manage IAM policies.

To make a policy effective, you need to bind it to a group.

  1. In the user menu, select Account settings.
  2. Go to Identity management > Group management.
    For details, see Manage group permissions with IAM policies.
  3. Edit the group to which you want to bind the policy.
  4. Select the Policies tab.

Managed

In Dynatrace Managed, only admin users can manage IAM policies (users with group with Cluster administrator permission selected).

If you have access to IAM policy management

  1. In the Cluster Management Console (CMC), go to User authentication > Policy management.
  2. Add, view, edit, and delete policies as needed.

To make a policy effective, you need to bind it to a group.

  1. In the Cluster Management Console (CMC), go to User authentication > User groups.
  2. Under Environment permissions and policies, edit an environment.
  3. Select the Policies tab.
  4. Select one or more policies.
  5. Select Bind policies.
I created a policy but cannot see its effects. What am I doing wrong?

To put a policy into effect, you need to

  1. Create the policy.
  2. Bind the policy to a user group.

See "Where can I manage policies in the web UI?" above.

Why don't I have access to settings? Is it a setting or IAM issue?

Make sure policies containing the following permissions are bound to one of your groups on the respective level (account, cluster, or environment):

  • settings:objects:read
  • settings:schemas:read
  • settings:objects:write
Why do I see the Settings menu even when I don't have policies bound?

Before you bind a policy, you will see the Settings menu items (RBAC settings) but without required permission; the items won't be accessible. After you bind the required policy, more Settings menu items (Settings 2.0) will appear.

Why do I see only part of the settings submenu?

When you see only part of the Settings menu, verify that the Change monitoring settings permission is assigned, or correct policies are bound to your group.

The recommended way to check if settings are Settings 2.0 is to see if an Info icon is displayed in the upper-right corner of the settings page.

Info icon on Settings page

Why can I change settings for environment X, but not for environment Y?

To manage settings access consistently across all your environments, the policies used to grant access need to be created and bound on the account (SaaS) or cluster (Managed) level.

If you grant access on the environment level, you need to do it for every environment where that access should be granted.