Extend flexible and granular access management for team enablement and autonomy at scale

The new Dynatrace authorization system based on security policies centralizes access management and provides granular permissions that support a variety of permission scenarios.

Observability is gaining more and more attention these days, with multiple teams across organizations leveraging the insights. Access requirements for users are typically dependent on the organizational structure of a company and how its roles and department structures evolve. It’s therefore necessary to make access management configurable at scale so that it can be easily adapted to changing requirements and enable a self-service culture.

Centralized approaches that rely on human administrators can lead to bottlenecks and friction in large-scale organizations. Coarse-grained access management controls can also result in compliance issues. If we’ve learned one thing about access management and enforcement, it’s that self-service approaches scale best as companies know best how their data needs to be accessed.

Tailor access management to your needs

Therefore, Dynatrace has built security policies that provide you with an easy way of defining data access that fits your organization. The security policy format provides a generic configuration pane for you to define access to your data. Not only are you able to control access based on permissions, you can also issue additional conditions to act on the accessed data. Such attributes can be, for example, the creator of a document, the name of a metric, or a custom region field that allows you to segment the data for access.

Especially for our new configuration framework (aka Settings 2.0), it’s important to establish control over how all settings are accessed. This was one of the most demanded features, and with the introduction of security policies, this control mechanism is finally available.

With security policies, a variety of use cases can be fulfilled for settings, for example:

• Read-only access to settings for audit purposes
• Granting select users access to a specific setting that’s critical for operation
• Providing access to a subset of settings to promote team autonomy
• Interaction with Dynatrace via API or the web UI

Let’s take a look at how the new permission system is leveraged within Settings 2.0 when giving access to a specific setting:

Here we see a policy for an SLO manager that restricts settings access to the SLO setting only. The new policy format provides granularity and flexibility and is still easy to read. Using the policy language, you can create a repository of security policies that reflect the access patterns of your organization.

Security policies can be bound to a user group in the same way as permissions. There is a new category for policies on the user group page that allows you to bind a policy to a specific environment for a user group.

As of today, many settings are already available to be referenced in security policies. To find out which settings are available in your environment, check out the Settings/schemas API.

Policy format

With the introduction of security policies, we’ve adjusted the granularity of permissions. Since the definition of access management through policies provides increased flexibility, increased granularity now supports a variety of permission scenarios. The permissions available in security policies allow you to control what is allowed per user on a per-action basis.

ALLOW permission WHERE attribute = value

Permissions

Permissions describe how to access a service/resource, whereas conditions provide further measures for granting access based on attributes that come from a service.

service:resource:action—Each permission includes a concrete action that acts on a specific resource that a service provides to a user.

Example

settings:objects:read—This permission describes the read permissions for objects on the settings service.

Attributes

service:attribute—Each attribute describes a variable that is provided by the service to control access to its resources.

Example

settings:schemaId = “builtin:monitoring:slo”—This condition restricts settings access to a specific schema ID.

Depending on the service, different attributes and permissions are available to give you control over data access. To take a deeper look into which services are available with security policies and what permissions and attributes they offer, please see the security policies service reference in Dynatrace Documentation.

Central authorization system for both web UI and API access

With the new authorization system based on security policies, Dynatrace provides a central point for access management. This means that all calls to Dynatrace are authorized in the same way, no matter if they come from the API or the web UI. This provides admins with a single configuration interface for user access that is enforced across all channels.

For policies to be enforced via the API, users need to create a personal access token so that the user identity is part of the request when the API is accessed. Based on the assigned policies of the user, the access decision is then made in the same way as with the web UI. So users can decide over which interface they want to consume the data.

Built-in automation

The new policy service was designed with API-first in mind, so everything that happens in the web UI is tied to the underlying policy management API. This makes automation easy and lets you realize complex workflows on top of our policies. The API is located in the Dynatrace Account Management API for SaaS deployments and in the Cluster API v2 for Dynatrace Managed.

What’s next

To find out more about how policies for settings are leveraged in Dynatrace and how settings work in general, check out these Dynatrace blog posts:

• Enable your teams to scale better with fine-grained settings and permissions for Digital Experience Management
• Scale self-service configuration of Davis notifications with secure automation options

We’ll continue to develop our security policies to support more services and provide better measures for access controls (for example, integration with the current concept of management zones). If you want to learn about the full details of Dynatrace security policies and their capabilities, please see Dynatrace Documentation.