Tailored access management, Part 2: Onboard users to Grail and AppEngine

In Part 1 of this blog post series, we introduced the concept of security policies in preparation for upcoming enhancements to the Dynatrace platform. Security policies give authorized users access to Dynatrace capabilities, such as Grail and its add-ons, exploratory analytics, and Dynatrace AppEngine.

Modern authorization concepts for the Dynatrace platform

With the introduction of Dynatrace Grail™ and AppEngine, we’re changing how access management is provided on the new platform. The new architecture enables more granularity in permission management and provides the dynamics necessary to serve modern access management use cases.
We’ve replaced the role-based permission system with security policies that provide fine-grained control over service access and introduce new dynamic controls for user authorization.
Dynatrace administrators must now set three permission types to ensure that users benefit from the latest platform capabilities.

• Permission to query data stored in Grail
• Permission to run and access Dynatrace® Apps
• Permission to access supporting services

Managed security policies

Managed security policies are used to assign permissions to users and simplify the configuration of access permissions without the hassle of dealing with all the fine-grained permissions in the Dynatrace IAM permission system. The managed policies cover the essential access scenarios that administrators face and can be used to conveniently set up more complex permissions. When there is a need for more customized access control, administrators can create their own policies.

Dynatrace offers a set of managed policies that cover standard use cases for accessing the new capabilities of the Dynatrace platform: AppEngine, AutomationEngine, and Grail. The managed policies always reflect the latest changes in the Dynatrace platform and its underlying permission system and, therefore, can’t be customized.

Security policies for granting platform access

Administrators can find the policies managed by Dynatrace in the policy overview in Account management and bind them to user groups just like any other policy. These policies are of type Dynatrace managed.

Policies can be assigned to groups via the user group details either on the account level, which includes all tenants in that account, or on the individual environment level.

The following section offers an overview of the managed policies available for Grail™ and AppEngine, which you can use to give your users access to these new capabilities.

Grant users basic access to AppEngine

AppEngine user policy

This policy provides basic access to AppEngine to run apps and functions and access the main supporting services (such as the state service, document service, or document sharing).

ALLOW app-engine:apps:run, app-engine:functions:run;
ALLOW automation:workflows:read, automation:rules:read, automation:calendars:read;
ALLOW document:documents:read, document:documents:write, document:documents:delete, document:environment-shares:read, document:environment-shares:write, document:environment-shares:claim, document:environment-shares:delete, document:direct-shares:read, document:direct-shares:write, document:direct-shares:delete;
ALLOW state:app-states:read, state:app-states:write, state:app-states:delete, state:user-app-states:read, state:user-app-states:write,state:user-app-states:delete, app-settings:objects:read;

AppEngine admin policy

This policy provides users full access to AppEngine, with write access to all services.

ALLOW app-engine:functions:run, app-engine:apps:run, app-engine:apps:install, app-engine:apps:delete;
ALLOW automation:workflows:read, automation:rules:read, automation:calendars:read;
ALLOW document:documents:read, document:documents:write, document:documents:delete, document:environment-shares:read, document:environment-shares:write, document:environment-shares:claim, document:environment-shares:delete, document:direct-shares:read, document:direct-shares:write, document:direct-shares:delete;
ALLOW state:app-states:read, state:app-states:write, state:app-states:delete, state:user-app-states:read, state:user-app-states:write, state:user-app-states:delete, app-settings:objects:read, app-settings:objects:write;
ALLOW settings:objects:read, settings:objects:write, settings:schemas:read where settings:schemaId startsWith "app:";

Give additional access to new platform capabilities

AppEngine developer

Add additional permissions that enable a user to develop and install custom apps

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

AutomationEngine access

Allows users to use the Workflows app and automation capabilities

ALLOW app-engine:apps:run WHERE shared:app-id = "dynatrace.automations";
ALLOW automation:workflows:read, automation:workflows:write, automation:workflows:run, automation:rules:read, automation:rules:write, automation:automations:run, automation:calendars:read, automation:calendars:write;

Grant access to data stored in Grail

Storage Default Monitoring Read

Administrators can use this permission to give users access to the tables and data stored in default buckets (default bucket names starts with default_). This policy will be adjusted automatically as new tables are added to Grail in the future.

Be aware that this policy only covers default buckets. Once custom buckets are added to Grail, administrators need to define additional permissions.

ALLOW storage:buckets:read WHERE storage:bucket-name startsWith “default_”;ALLOW storage:events:read, storage:logs:read, storage:metrics:read, storage:entities:read, storage:bizevents:read, storage:spans:read;

Storage Read per table

Each table includes a policy that combines table and bucket access called Storage <tablename> Read. Administrators can use this policy to grant a user group access to a certain table and the assigned buckets.

ALLOW storage:buckets:read WHERE storage:table-name = “logs”;
ALLOW storage:logs:read;

Storage All System Data Read

The Storage All System Data Read policy grants access to Dynatrace internal data such as auditing events and query execution events. Administrators can add this policy to those users that need access to this type of data.

ALLOW storage:buckets:read;ALLOW storage:system:read;ALLOW storage:events:read, storage:logs:read, storage:metrics:read, storage:entities:read, storage:bizevents:read,storage:spans:read;

Storage All Grail Data Read

This policy grants unfiltered access to all data in Grail.

ALLOW storage:buckets:read;
ALLOW storage:system:read;
ALLOW storage:events:read, storage:logs:read, storage:metrics:read, storage:entities:read, storage:bizevents:read,storage:spans:read;

For full details, see bucket and table permissions for Grail documentation.

Auto-migration for environment admins and default user groups

To make the initial setup more convenient, we auto-assigned AppEngine, AutomationEngine, and Grail policies to existing admins in each Dynatrace environment.

Every user group with permission to change settings receives the respective admin policies for AppEngine and Grail. This means every environment admin is automatically assigned the policies AppEngine Admin, AutomationEngine Access, and Storage All Grail Data Read.

Automate policy assignment via IAM APIs

To automate the above-mentioned policy management or to automatically provision users with the proper privileges, please use our IAM APIs, which can be found at api.dynatrace.com as part of the Account management API.

Use the bindings endpoint in the Dynatrace Account Management API to assign managed policies to user groups.

Pro tip: Notebooks migration script

The newly introduced Dynatrace Notebooks allows you to run custom code using AppEngine. We created a script that helps administrators easily migrate existing platform-access permissions for all users—just add and execute the script to any notebook after providing OAuth client credentials for the account that needs to be migrated with the following OAuth scopes assigned:

• account-idm-read
• iam-policies-management

This script crawls the entire account and identifies the user groups with Viewer access to the environments. It then creates the new policy bindings for AppEngine and Grail based on the existing role-based permissions.

Head over to Dynatrace Community to download the script, get support, or ask any related questions.

What’s next

To learn more about how to manage policies within Dynatrace IAM, see Dynatrace Documentation and Part 1 of this blog post series.

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.