Manage policies and groups with Dynatrace IAM

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.

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.

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.

Only admin users can manage IAM policies.

• SaaS: users with account permission Manage users
• Managed: users with group with Cluster administrator permission selected

• 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.

• 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.

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.

Dynatrace version 1.226+

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.

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.

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

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.

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.

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

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.

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.

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.