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
andhardening
ALLOW environment:roles:manage-settingsWHERE environment:management-zone IN ("dev", "hardening"); - Read access in
prod
ALLOW environment:roles:viewerWHERE 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-settingsWHERE 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:logviewerWHERE environment:management-zone IN ("my-management-zone");
Role names
Use the following role names in your policy statements.
roles:viewer
roles:manage-settings
roles:configure-request-capture-data
roles:agent-install
roles:manage-security-problems
roles:view-security-problems
roles:replay-sessions-without-masking
roles:replay-sessions-with-masking
roles:logviewer
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.