Header background

Tailored access management for Dynatrace, Part 1: One configuration for all authorization requirements

This is part one of a blog post series explaining how to use security policies to set permissions within Dynatrace. In this post, you'll learn about the new permissions for environment roles, which extend the coverage of our security policies.

Typically, within larger enterprises, multiple teams work with software intelligence and observability solutions such as Dynatrace. Such environments need flexible access management that’s configurable, highly scalable, and easily adaptable to changing access requirements.

Security policies ease permissions administration

Some time ago, we introduced security policies for our configuration framework (aka Settings 2.0) to give you more control over how your Dynatrace environments are configured. Over the course of the last year, we’ve incrementally extended the coverage of security policies to provide a common authorization mechanism for the entire Dynatrace platform. Our main focus has been to enable fine-grained access controls for settings, thus enabling teams to control their own subset of settings while driving autonomy across the organization. These capabilities are not only viable for Settings 2.0—they also provide value in other areas of the product.

Having a configurable, flexible, and centralized system for authorization reduces management effort and allows you to handle complex authorization requirements. The new access control offering furthers our goal of building intrinsically valuable generic capabilities into the Dynatrace platform. We want to provide you with all the tools necessary to manage the authorization requirements that you face now and will encounter in the future.

Security policies leverage reusability to provide value for your environment: you define a particular authorization scenario in your system, create the respective policy that reflects the required privileges, and assign the policy to the groups that should be granted the defined access permissions. This approach improves authorization consistency and manageability in your environment as the policy abstracts part of the complexity and provides a reusable authorization building block.

Introducing environment permissions

With the introduction of environment permissions, we now enable admins to manage end-to-end access to Dynatrace environments using only security policies. This removes the duality of role-based permissions for environment access and attribute-based permissions for all other access in the new authorization system. Now, you can use one central interface—security policies—to define user/group authorization for your environment via the Dynatrace web UI and API—everything is now covered by a single security policy.

Environment permissions with policies

To make the migration to policies easier, you can express existing RBAC permissions as policies. This way, you can use the policy language to define both old and new permissions on the Dynatrace platform.

environment:roles:viewer
environment:roles:manage-settings
environment:roles:agent-install (*)
environment:roles:view-sensitive-request-data
environment:roles:configure-request-capture-data (*) 
environment:roles:replay-sessions-without-masking
environment:roles:replay-sessions-with-masking
environment:roles:manage-security-problems
environment:roles:logviewer

supported attributes:
    environment:management-zone

(*) environment:management-zone attribute not applicable

Example: Setup for a typical application developer

With full access in dev and hardening, and read access in production.

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

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

Example: Monitoring different parts of the environment

First, we grant full access to the environment:

ALLOW environment:roles:viewer, environment:roles:manage-settings;
Once we have full access, we are able to see all management zones
Once we have full access, we can see all management zones

In the next step, we limit access to management zones based on prefix labels, in this case, [Kubernetes].

ALLOW environment:roles:viewer, environment:roles:manage-settings
WHERE environment:management-zone startsWith "[Kubernetes]";
Result of new policy - access is limited to two management zones.
Result of the new policy: access is limited to two management zones.

Extended coverage for security policies

Let’s look at some of the other new permissions that we support in security policies and adjacent use cases. For the complete list of supported services, see our IAM service reference.

Control of extensions management

Here’s the list of new available permissions for extension management:

extensions:definitions:read
extensions:definitions:write

supported attributes: 
    extensions:extension-name
extensions:configurations:read
extensions:configurations:write

supported attributes: 
    extensions:host
    extensions:host-group
    extensions:ag-group
    extensions:management-zone

Example: Delegate extension ownership

To highlight the use of these permissions, we’ll first set a policy that allows users to activate and configure a specific extension in your environment:

ALLOW extensions:definitions:read, extensions:definitions:write;
WHERE extensions:extension-name = "com.dynatrace.extension.active-directory";
ALLOW extensions:configurations:write, extensions:configurations:read;

We can create another rule that allows users to activate extensions and configure them only for a specific host group in your environment. Use the host group ID in your condition:

ALLOW extensions:definitions:read, extensions:definitions:write;
ALLOW extensions:configurations:write, extensions:configurations:read
WHERE extensions:host-group = "HOST_GROUP-E5345FB4F8B50C48";

Cloud Automation fine-grained permissions

Policy-based access control is also available within Cloud Automation. With the newly introduced policies, in addition to the general user roles, you can define fine-grained permissions on Cloud Automation entities and define user groups such as Developer, Product Engineer, or other.

Please see our Fine-grained access controls blog post for further details about the new permissions for Cloud Automation.

Fine grained permissions in Dynatrace Cloud Automation

What’s Next

Are you interested in learning more about how tailored access control works in Dynatrace? If so, check out our Extend flexible and granular access management for teams blog post to understand the basic architecture and have a look at our documentation. And, of course, watch out for part two of this blog post series, where we’ll show you how to use the new central configuration interface to bring new dynamics to your authorization system.

Once you’ve started working with policies, we’d love to hear your feedback: let us know your thoughts or share your ideas about how we should continue to enhance authorization settings in Dynatrace.