Set up Grail permissions for Snapshots

• Latest Dynatrace
• How-to guide
• 2-min read
• Updated on Mar 16, 2026

Dynatrace has a permission model for Grail. This applies to all telemetry data, such as 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 like 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 enabled.

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 mentioned deployment-relevant primary Grail fields.

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:

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

Set up security context

If the permissions on deployment-level attributes or the bucket level are insufficient, Dynatrace allows you to set up fine-grained permissions by adding a dt.security_context attribute to your data. This context can represent your security architecture and could even be hierarchical by encoding this into 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.

Leverage 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.

Enforce access control to snapshots

You can enforce access to the snapshots in Grail by leveraging existing attributes in your snapshots. Use policies to properly control access to the application.snapshots bucket.

ALLOW storage:application.snapshots:read WHERE storage:dt.security_context = "TeamA" AND storage:k8s.namespace.name = "easytrade"