Manage user permissions with IAM policies
Use Dynatrace identity and access management (IAM) to manage user access to Dynatrace features.
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
Frequently asked questions
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 View and manage users and groups
- Managed: users with group with Cluster administrator permission selected
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.
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
- In a Dynatrace Managed deployment, this is
environment: Environment policies apply only to a single customer environment.
There is an internal limitation of 200 policies. You may have reached the limit.
To put a policy into effect, you need to
Create the policy.
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):
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 Manage 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.