• Home
  • Manage
  • Access control
  • User management and SSO
  • Manage user groups and permissions
  • Manage policies and groups with Dynatrace IAM
  • Migrate role-based permissions to Dynatrace IAM

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.

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
    plaintext
    ALLOW environment:roles:manage-settings WHERE environment:management-zone IN ("dev", "hardening");
  • Read access in prod
    plaintext
    ALLOW environment:roles:viewer WHERE environment:management-zone IN ("prod");

Example 2: monitoring parts of the environment

  1. Create a policy granting full access to the environment.

    plaintext
    ALLOW environment:roles:viewer, environment:roles:manage-settings;
  2. A user from a group to which this policy is bound has full access to the environment.

    Full access

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

    plaintext
    ALLOW environment:roles:viewer, environment:roles:manage-settings WHERE environment:management-zone startsWith "[Kubernetes]";
  4. Now the user has access only to the management zones with names starting with “[Kubernetes]”.

    Roles limited access

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:

plaintext
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 nameIAM role nameManagement zone condition
Access environmentroles:viewer
Change monitoring settingsroles:manage-settings
Configure capture of sensitive dataroles:configure-request-capture-data
Download/install OneAgentroles:agent-install
Manage security problemsroles:manage-security-problems
Replay session data without maskingroles:replay-sessions-without-masking
Replay session dataroles:replay-sessions-with-masking
View logsroles:logviewer
View sensitive request dataroles:view-sensitive-request-data

As with classic role-based permissions, the viewer role is a part of any other role. For example, a policy with a manage-settings role also allows a user to access 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.

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

Use the following syntax in your policy statements.

  • Allow a role
    plaintext
    ALLOW environment:roles:<role name>;
  • Allow a role in a management zone
    plaintext
    ALLOW environment:roles:<role name> WHERE environment:management-zone = "<name of management zone>";
  • Allow a role in a number of management zones
    plaintext
    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.