Our customers use Dynatrace to transform and improve the way they work. The Dynatrace Software Intelligence Platform provides automatic and intelligent observability for multiple teams across development, operations, and line of business. As these teams use Dynatrace for multiple use cases in the world’s largest environments, manageability at scale is key.
Our new permissions framework for settings makes it easier than ever to distribute the management of various monitoring settings, anomaly detection and alerting settings, integration with 3rd party services, and many other settings to the teams who need them.
This enables Dynatrace administrators to:
- Provide fine-grained access control to settings, no matter if accessed via our web UI or API.
- Quickly enable teams with the settings they need to achieve their goals while providing autonomy via distributed settings management.
- Ensure easy manageability of Dynatrace as your organization scales.
New authorization for Settings 2.0
Dynatrace monitoring settings benefit from the new authorization framework by allowing users who don’t have privileges on an environment level to change certain settings. So rather than granting settings access on a global level or per management zone, it’s now possible to create security policies that define what individual users are allowed to see and which settings they are allowed to edit.
The following features are available with the preview for security policies:
- Streamlined access to Setting 2.0 over web UI and API with central policy enforcement
- Policy management and orchestration over UI/API
- New policy expression language for defining authorization
Manage access to settings using security policies
As mentioned above, the new access management system relies on policies instead of static predefined roles. This allows the system to adapt to changing requirements and provides more fine-grained control over access to sensitive resources. The first level of access control that can be protected using security policies is the service level. Every service exposes a set of permissions that are tightly coupled to its API design and provide a resource-oriented means of defining user access. With these permissions, API access can be secured from the end user’s perspective.
The following service-level permissions are now available for settings:
settings:objects:readsettings:objects:writesettings:schemas:read
In addition to service-level permissions, the policies can be extended to not only control access on the API level, but to give finer control over which data is exposed by the respective endpoint. This is realized through attributes that are provided by the service and which can be formulated into conditional rules for access control. These privileges can be stated in security policies to enable customized access enforcement. Currently, the settings service provides an attribute for settings:schemaId which allows you to state conditions to restrict access to specific settings.
To sum up, service-level permissions allow you to control whether a user has permission to interact with a certain service; with attributes you can focus on a subset of data that the user is allowed to access, to make your access policies more precise.
Example
ALLOW settings:objects:read, settings:schemas:read
WHERE settings:schemaId = “builtin:monitoring.slo”Effects of policies for settings
Settings 2.0 web UI
The new settings 2.0 user interface reflects the permissions that are granted to the user via policies. This means that a setting can only be opened if the user has read permissions for that specific setting. If both read and write permissions are granted to the user they will be allowed to open related settings pages and to save changes.
Settings 2.0 API
The settings API represents the whole settings framework in two distinct resource types, objects and settings. Since our new permission system is also resource-oriented, you have the same resource names for defining the access policies. This means that you can create policies that include read and write permissions on objects and schemas.
Important things to note
For access to the settings 2.0 API, a user needs to create a personal access token. This is because the user identity must be carried along when accessing the API to reference the correct policies and to enforce the users permissions. To learn how to activate this feature and to create such a token, see the blog post Securely scale your API operations with personal access tokens.
Currently, authorization based on security policies runs in parallel to the existing role-based permissions of Dynatrace. This means that when the policies are activated, everything works as before, but you have the possibility to grant other users who are currently unprivileged with access rights to specific settings. All existing user permissions will be retained and unaffected by any new policies. The defined policies are currently purely additive which means that an admin who has configuration access rights won’t lose access during the preview.
Preview scope and outlook
An important perspective on access management is organizational scaling, which means providing teams fine-grained permissions to a subset of the data that fosters autonomy and enablement across all teams. When providing generic data interfaces for access to all data, it’s of extreme importance to also provide fine-grained and configurable authorization mechanisms.
This is why we up-levelled our permission system, moving away from our static permission system. The policies allow you to configure the access patterns in a flexible way so that they suit your specific use cases and user groups. With the new framework we allow customers to scale their permissions and fit them to their organizational structure.
Another important consideration that we are solving with the new authorization system is harmonization of permissions across the API and web UI. As security policies become the single source of truth for access management, each user’s assigned policies determine what data they can access via either interface. In essence, the way that data is accessed has no influence on the enforcement of a user’s permissions; there is a security policy that serves as a single enforcement point per service that determines whether data access is allowed or denied.
From this preview release, onwards we will continue to evolve our new authorization framework and will start to cover more and more services. Based on the feedback that we receive we will continue to improve our policy expression language and management capabilities, so that in the end you will have a powerful framework that acts as a single source of truth for access management across all services inside and related to the Dynatrace platform.
Ready to get started?
If you want to join our preview program and experience the power of our policy system please sign up to join the preview today.
Disclaimer
The scope and features provided during the Preview are subject to change. The goal of the program is to collect early feedback from selected customers to improve the final product.
Looking for answers?
Start a new discussion or ask for help in our Q&A forum.
Go to forum