New RUM Experience permissions

Latest Dynatrace
Reference
1-min read

Using the New RUM Experience requires the permissions described below. For details on granting permissions, see Working with policies.

Permissions for apps

To list and run the apps provided by the New RUM Experience, you need app-engine:apps:run permissions for them. The table below lists the apps and their IDs.

App	App ID
Experience Vitals	`dynatrace.experience.vitals`
Error Inspector	`dynatrace.error.inspector`
Users & Sessions	`dynatrace.users.sessions`

Table permissions

To access the data captured by the New RUM Experience in Grail, the following table permissions are required:

IAM permission	Description
storage:user.events:read	Grants permission to read records from the events table.
storage:user.sessions:read	Grants permission to read records from the session table.
storage:metrics:read	Grants permission to read timeseries from the metrics table.
storage:smartscape:read	Grants permission to read Smartscape nodes and edges from Grail.
storage:user.replays:read Preview	Grants permission to access replay data in Grail.
session-replay:resources:read Preview	Grants permission to access CSS resources.

Optional permissions:

IAM permission	Description
session-replay:sessions:replay-without-masking Preview	Allows replay without playback masking settings.

For details on how to join the preview program, see Preview program.

Record-level permissions

Grail supports the definition of fine-grained permissions at the level of individual records by adding a WHERE clause to table permissions; see Permissions in Grail. Among the supported fields, the following are relevant for the New RUM Experience.

Frontend name

The field storage:frontend.name allows the definition of policies at frontend level, for example:

ALLOW storage:user.events:read WHERE storage:frontend.name="my_frontend";

Security context

Dynatrace allows fine-grained permissions by adding a dt.security_context attribute to specific data using OpenPipeline; see Configure advanced permissions with security context. This field is also applicable to user events and user sessions.

Bucket permissions

You can restrict access to data stored in:

Default (built-in ) buckets.
Custom buckets.

For example, suppose you want to allow specific users to query user events and sessions stored in custom buckets in a specific frontend.

Create two custom buckets, for example, rum_checkout_user_events and rum_checkout_user_sessions. You need to create two separate custom buckets because user events and user sessions are stored in different tables (user.events and user.sessions).

Set up permissions so that users can query only data from the two specified buckets, and only for records where storage:frontend.name is SpecificFrontend.

ALLOW storage:buckets:read WHERE storage:bucket-name IN ("rum_checkout_user_events", "rum_checkout_user_sessions");
ALLOW storage:user.events:read WHERE storage:frontend.name="SpecificFrontend";
ALLOW storage:user.sessions:read WHERE storage:frontend.name="SpecificFrontend";

Field permissions

By default, fields containing sensitive information—namely client IP addresses, geographic latitude and longitude, and user identifiers—aren't accessible in the user.events and user.sessions tables. These fields belong to the predefined builtin-sensitive-user-events-and-sessions fieldset, which hides them from query results unless explicitly allowed. This restriction applies to both DQL and the data displayed in apps.

The builtin-sensitive-user-events-and-sessions fieldset includes all fields described in Sensitive user.events and user.sessions fields, as well as the deprecated field dt.rum.user_tag.

To access these fields, you must have permission to access the fieldset. This permission can be granted using the following policy statement:

ALLOW storage:fieldsets:read WHERE storage:fieldset-name="builtin-sensitive-user-events-and-sessions"

For more information about predefined fieldsets, see Field permissions.

Event and session properties may also contain sensitive information. To restrict access, define a custom fieldset as described in Define custom fieldsets via API.

Settings permissions

Several settings schemas are available for RUM. These schemas start with the prefix builtin:rum and are listed in Settings 2.0 - Available schemas. Most of these schemas are not only relevant for RUM Classic, but also for the New RUM Experience. Health alert configuration uses the additional schema builtin:health-experience.frontend-alert.

Read permissions for RUM settings are recommended for all users of the New RUM Experience. If you need to instrument and configure frontends in the New RUM Experience, you also need write permissions. For details about controlling access to settings, see Grant access to Settings.