Migrate role-based permissions to Dynatrace IAM

Dynatrace version 1.252+

Dynatrace security policies now support the classic role-based permissions, which means that you can control all access to a Dynatrace environment using only the IAM framework and use security policies to define user/group authorization in your environment via either the Dynatrace web UI and or the Dynatrace API.

Attribute-based access control

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

How is ABAC different?

Compared to our classic role-based access control, 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 ABAC to me?

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

Administration of permissions is easier and more scalable. You can manage policies through Account Management or via the Dynatrace Enterprise API.
You can 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, policies provide granular access to all Dynatrace services so you can grant each user exactly the right amount of access.

How does ABAC improve data security?

Security policies are designed first and foremost to make Dynatrace safer.

Security policies enable admins to more selectively grant permissions based strictly on necessity, following the principle of least privilege (PoLP).
With security policies, you can 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 that, you would have to assign the user a role for which such fine-grained control is not possible.
Security policies help to make Dynatrace permissions easier to understand, which means admins can more reliably administer permissions.

For details on attribute-based access control and security policies, see Working with policies.

Environment permissions

To ease migration to security policies, you can now use existing environment permissions in your policy statements and bind them to groups.

Example 1: policy for an application developer

For example, to create a policy for a typical application developer, you'd want to provide them with the following:

Access to all settings in dev and hardening

ALLOW environment:roles:manage-settings
WHERE environment:management-zone IN ("dev", "hardening");

Read access in prod

ALLOW environment:roles:viewer
WHERE environment:management-zone IN ("prod");

Example 2: monitoring parts of the environment

Create a policy granting full access to the environment.

ALLOW environment:roles:viewer, environment:roles:manage-settings;

A user from a group to which this policy is bound has full access to the environment.

Modify the policy to limit access to selected management zones based on name prefix (in this example, “[Kubernetes]”).

ALLOW environment:roles:viewer, environment:roles:manage-settings
WHERE environment:management-zone startsWith "[Kubernetes]";

Now the user has access only to the management zones with names starting with “[Kubernetes]”.

Learn how to create policies.

Management zone permissions

To create a management zone permission to IAM, use the environment:management-zone attribute in your policy statement. For example, to limit log viewing to a selected management zone, use the following statement:

ALLOW environment:roles:logviewer
WHERE environment:management-zone IN ("my-management-zone");

Role names

Use the following role names in your policy statements.

Current role name

IAM role name

Management zone condition

Monitoring data access

View environment

roles:viewer

Manage monitoring settings

roles:manage-settings

Manage capturing of sensitive request data

roles:configure-request-capture-data

Install OneAgent

roles:agent-install

Manage security problems

roles:manage-security-problems

View security problems

roles:view-security-problems

Replay sessions without masking

roles:replay-sessions-without-masking

Replay sessions with masking

roles:replay-sessions-with-masking

View logs

roles:logviewer

View sensitive request data

roles:view-sensitive-request-data

Role permissions can be divided into two groups:

Permissions granting access to monitoring data
Permissions that can be used to extend basic monitoring data access, which on their own do not grant access to the environment

For example, a policy with a manage-settings role also allows a user to access the web UI, but a policy with a logviewer permission also requires viewer permission to grant access to the web UI.

Policy statement syntax

In its most basic form, a policy statement for environment permissions starts with the ALLOW keyword, which is followed by environment:roles, and then a role name. A statement can include an optional management zone condition.

ALLOW environment:roles:<role name> WHERE environment:management-zone = "<name of management zone>";

Use the following syntax in your policy statements.

Allow a role
```
ALLOW environment:roles:<role name>;
```

Allow a role in a management zone

ALLOW environment:roles:<role name> WHERE environment:management-zone = "<name of management zone>";

Allow a role in a number of management zones

ALLOW environment:roles:<role name> WHERE environment:management-zone IN ("<name of management zone 1>", "<name of management zone n>");

Policies don't restrict classic role-based permissions

As you migrate your role-based access to IAM framework, note that role-based permissions and security policies are additive. This means that you can't limit an environment permission with a more restrictive policy.

For example, if an environment permission is assigned to a user, and then you assign this user to an IAM group with a policy-based role restricted to a management zone, the environment permission still grants access to a whole environment, including all management zones.

User search limitation

While performing a user search (for example, when trying to share a dashboard), some users might not appear in the results. This is currently a known limitation that affects users who have only IAM policies, without any role-based permissions. As a workaround, please assign any permission to such a user and they will then appear in the user search results.