Migrate role-based permissions to Dynatrace IAM policies

Dynatrace version 1.266+

This guide gives an overview and comparison of role-based access control (RBAC) and attribute-based access control (ABAC), and provides guidelines and recommendations to consider when planning your migration from RBAC to ABAC.

The guide is primarily intended for use by account administrators wanting to take advantage of the power of the ABAC framework within Dynatrace.

What is ABAC?

ABAC is the preferred industry-wide access management framework because of its business-oriented and modern approach to defining security policies through logical, plain language.

It defines access to secure resources based on a combination of user, resource, action, and contextual attributes. It uses security policies as a mechanism to define access rules for resources.

Understanding the Difference: RBAC vs ABAC

RBAC roles are typically created to map work functions, such as department, seniority, or work assignment. RBAC permissions typically grant all-or-nothing access to resources based on pre-defined static roles.

For example, assigning "View Logs" permission to a group in Dynatrace grants users in that group the ability to view all captured logs. There is no ability to further refine their access to the logs.

ABAC, on the other hand, determines user access by evaluating resource, data, user, and contextual attributes, along with the specific user action being requested. This provides for a flexible permissions framework that handles changes in access requirements in a more dynamic way, rather than relying on static RBAC roles. Furthermore, the access control granularity offered makes it possible to design common or complex access requirements.

Dynatrace’s IAM permissions framework uses these core ABAC principles and further enhances them with features like policy templating, policy boundaries, and default policies to make our implementation of ABAC more flexible and user friendly.

ABAC implementation in your Dynatrace

The Dynatrace IAM permissions framework currently supports the classic RBAC as well as the newer, ABAC, which leverages security policies to define permissions. Security policies are stand-alone components of the ABAC framework that allow combining one or many policy statements to define conditional access to your Dynatrace resources.

The access permissions defined in a security policy take effect when that policy is bound to a group, thus directly controlling the permissions of the users of that group. For simplicity, we will refer to security policies as simply policies for the remainder of this guide.

The following diagram captures the relationship between users, groups, policies, and policy boundaries.

Policies leverage user, resource, data, and contextual attribution to enable you to configure access to your Dynatrace secure resources. You can secure individual data resources, apps, and services while optionally specifying business-specific access control conditions through the expressiveness of the policy statements syntax.

One or many policy statements can be combined into one policy. The policy can then be bound to one or many user groups, ultimately granting the users of those group the resource access defined by the policy.

For example, the Dynatrace ABAC policy below grants the ability to install or delete (action) custom apps (resource) where (condition) app identifier (resource attribute) is prefixed with "custom" (attribute value):

ALLOW app-engine:apps:install, app-engine:apps:delete WHERE shared:app-id startsWith “custom”;

The next example leverages additional contextual information (the time of the day) to restrict the ability to run apps only within business working hours.

ALLOW app-engine:apps:run WHERE shared:app-id = "dynatrace.automations" and global:time-of-day > "09:00+01:00" AND global:time-of-day < "17:00+01:00";

Classic RBAC roles can also be expressed in policies. For example, the policy statement below grants environment access but only for a specific management zone.

ALLOW environment:roles:viewer WHERE environment:management-zone=”mgmt-eu”

The ability to include classic RBAC roles in your policy statements is a very important feature of ABAC policies to help you transition from RBAC.

The true power of the Dynatrace ABAC framework lies in its ability to dynamically target individual or groups of platform resources, while optionally combining available attributes to further narrow down access parameters using the expressive nature of policy statement syntax.

Benefits of Migrating to ABAC

Dynatrace’s ABAC permissions framework offers the following advantages:

Security and compliance

Flexibility

Scalability

Granularity

Usability

Futureproofing

RBAC to ABAC migration planning

The following migration guide recommends a strategy and best practices to consider when planning and executing a migration from RBAC to ABAC.

Migration guidelines

The migration strategy you choose will depend on your current Dynatrace configuration.

The general strategy is to:

You can use these sample Dynatrace Notebook or this PowerShell scripts to give you an initial assessment and some recommendations to get you started. We will use the script output from our sample Dynatrace environment to illustrate some important concepts and best practices you should consider as you plan your ABAC migration.

Your Dynatrace RBAC assessment

A migration plan should start with an assessment of your current RBAC configuration. This means identifying existing RBAC roles assigned to your groups. We are interested in RBAC role assignments that are scoped to target environments or management zones.

Consider the steps below to conduct an initial assessment. You can use the Account Management portal to complete the steps or import and use the provided notebook to help you. Alternatively, you can also use the provided PowerShell script.

Migration to ABAC

With the inventory of assigned RBAC permissions already created, you can now map RBAC permissions to ABAC ones. You should give priority to existing default policies whenever possible, as opposed to building your own custom policies.

We will use ‘group_na_supp’ to help us illustrate some key best practices you should consider for your ABAC configuration.

This group currently has the following RBAC permissions scoped to two management zones ‘mgmt_na_east’ and ‘mgmt-na_west’:

If we were to create a new custom policy to assign those permissions, we could write the following policy statement:

ALLOW  environment:roles:replay-sessions-with-masking, environment:roles:replay-sessions-without-masking, environment:roles:manage-settings, environment:roles:view-sensitive-request-data , environment:roles:manage-security-problems, environment:roles:logviewer
WHERE environment:management-zone startsWith "mgmt_na";

We could then bind this policy to the group_na_supp group and remove the old RBAC role assignment from the group. To further optimize our new ABAC permission, we could use Dynatrace Professional rather than building a custom policy. Because default policies are read-only, we would need a mechanism to append our WHERE condition above.

This is where policy boundaries come into play. We can store the condition environment:management-zone startsWith "mgmt\_na"; in a policy boundary and then use it with our group, as we bind the group to the Dynatrace Professional policy, thus further restricting this permission assignment using the boundary we created.

First, let’s create the policy boundary. In Account Management, under Identity & Access management > Policies, we can create a policy boundary specific to North America management zones.

Next, we assign the default policy Dynatrace Professional to the group_na_supp and apply the boundary we just created.

As may be obvious from this example, policy boundaries make it possible to extract your business-specific access requirements out of the policy and into a standalone unit that can be re-applied over and over across multiple policies. Policy boundaries can be assigned to one or many group-to-policy bindings, making them reusable. The combination of default policies with policy boundaries has the potential to further simplify your permissions configuration.

When should you create custom policies

Rather than creating new custom policies, administrators are strongly encouraged to primarily leverage default policies, which are built and managed by Dynatrace and already encapsulate the necessary policy statements for typical access scenarios. When assigning these default policies to groups, you can then further restrict the permissions by using policy boundaries.

In cases where default policies do not meet your specific permission requirements, or when you might want to restrict them with some specific DENY statements, you can then build custom policies.

Testing and validation

We recommend mocking up groups and users and testing separately, ideally in a sandboxed environment if possible.

Also, Dynatrace’s Enterprise API could be used to provide useful permissions information for specific users or groups. For example, the following GET request to https://api.dynatrace.com will return current permissions for a specific user:

`https://api.dynatrace.com/iam/v1/resolutionaccount/:accountIdHere/effectivepermissions?entityType=user\&entityId=:userIdHere`

Deployment

Deploy policies in a phased approach to minimize user access disruptions. You may choose to do these in batches of groups or some other way more appropriate to your setup.

Monitoring and tuning

Monitor your ABAC permissions over time to see if they have adversely affected user access and adjust accordingly.

Migration support

Refer to our online documentation and Dynatrace Community forums for additional help during migration. Additionally, make use of Dynatrace’s support channels for more targeted help.

Final checklist