Set up Grail permissions for Services

• Latest Dynatrace
• How-to guide
• 4-min read
• Published Oct 06, 2026

The Dynatrace platform provides a comprehensive permission model for Grail. This model applies to all telemetry data, including metrics, events, spans, and logs.

We recommend setting up permissions along organizational lines and deployment scopes. Suitable concepts include host groups, Kubernetes clusters, and Kubernetes namespaces. These attributes are typically available for all telemetry data ingested via Dynatrace collection methods, such as OneAgent, OpenTelemetry, or Kubernetes operator. Hence, you can use these attributes to enable record-level permissions.

For Kubernetes-based deployments, make sure Dynatrace Operator has metadata enrichment activated.

If you only require a basic permission concept, setting up bucket-level permissions is the best option. You can then route your data to the correct bucket in OpenPipeline by matching one of the deployment-relevant primary Grail fields, such as host groups, namespaces, or clusters.

For more control in Dynatrace, you can set up policy boundaries with more granular restrictions on a data level. By default, you can use the following attributes:

Set up security context

Add security context to your data

If the permissions on deployment-level attributes or the bucket level are insufficient, you can set up fine-grained permissions by adding a dt.security_context attribute to your data. This context can represent your security architecture, and you can make the context hierarchical by encoding the hierarchy in a string, such as department-A/department-AB/team-C.

To use dt.security_context and other attributes for permissions, make sure these attributes are present in your telemetry data.

Use existing tags at the source

You can define the security context at the source via OneAgent, OpenTelemetry, or Kubernetes labels or annotations. This allows you to use your existing labels and tags to facilitate permissions in Dynatrace.

Set up security context in OpenPipeline

You can define a security context based on existing resource attributes from your span data within OpenPipeline.

After setting up dt.security_context, verify that your security context is set correctly.

When new span data arrives, the OpenPipeline security context processors add a dt.security_context attribute to the matching span records. To confirm that your security context processors handled the span records, go to Notebooks and run a DQL query, for example:

fetch spans | filter isNotNull(dt.security_context) | fields dt.service.name, dt.security_context

Based on the created attribute, you can enforce security-related user and group policies.

Access security context from service metrics and service entities

Once dt.security_context is set, you can use it to filter and group service data in DQL queries.

To query service metrics by security context, use the timeseries command and group by dt.security_context and dt.smartscape.service:

timeseries median(dt.service.request.response_time), by:{dt.security_context, dt.smartscape.service}
| filter isNotNull(dt.security_context) and isNotNull(dt.smartscape.service)

To query service entities with an assigned security context, use smartscapeNodes. See Explore the service entity in Smartscape on Grail to learn more about querying entities from Smartscape.

smartscapeNodes "SERVICE"
| filter dt.security_context != array()

The query returns all service entities where dt.security_context is set, allowing you to verify which services are covered by your security context configuration.

Next steps

Create policies and policy boundaries that use dt.security_context to control who can access your service data. For details, see Permissions in Grail.

To explore your services further, see Explore the service entity in Smartscape on Grail.