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
hardening, and read access in
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;
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]";
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.
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.