Set up Grail permissions for Metrics

  • Latest Dynatrace
  • How-to guide
  • 2-min read
  • Published Oct 27, 2025

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, Kubernetes operator, etc. Hence, these attributes can be used 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:

  • dt.host_group.id
  • host.name
  • k8s.cluster.name
  • k8s.namespace.name
  • Any other attribute listed in the permission model

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.

Set up the security context in OpenPipeline

You can define a security context based on existing resource attributes for your data within OpenPipeline. Go to Settings Settings > Process and contextualize > OpenPipeline: > Metrics > Pipelines and after configuring your pipeline, on the Permission tab, use the Set Security Context processors option.

To define the dt.security_context attribute

  1. Define a matching condition to filter metric records to assign the security context, such as:

    matchesValue(metric.key, "http.server.request.duration_bucket") and matchesValue(http.route, "/basket")

  2. Add the dt.security_context for those metric records. The value of this attribute can be a literal value such as TeamA, or a value copied from another field present on the metric record.

  3. Verify your security context is set correctly.

When new metric data arrives, the OpenPipeline security context processors add a dt.security_context attribute with the value TeamA to the matching metric records. To confirm that your security context processors handled the metric records, open Notebooks Notebooks and run a DQL query such as:

timeseries median(http.server.request.duration_bucket), by:{http.route, dt.security_context} | filter matchesValue(dt.security_context, "TeamA")

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

Related tags
Dynatrace Platform