The dt.security_context field is a core Grail attribute that enables fine-grained, record-level access control on all telemetry data. It is part of the primary Grail field set and, once set on a signal, propagates to all derived data, including Davis events and problems.
Security context is the right choice when deployment- or bucket-level permissions are insufficient.
Typical scenarios include:
If your organization can rely on deployment-level primary Grail fields such as k8s.namespace.name or dt.host_group.id for access control, you may not need dt.security_context at all. It becomes essential when the same deployment scope contains data that different audiences need access to.
Set the dt.security_context field as early as possible in the data pipeline, ideally at the source.
The following patterns are listed in order of preference.
At-source enrichment is always preferred over OpenPipeline-based enrichment for the security context. Setting security context at the source ensures it is available before pipeline routing, so data is routed to the correct pipeline and bucket from the start.
This is the preferred pattern.
Set dt.security_context at the point where telemetry is generated:
dt.security_context=<value> as a host tag during installation or via Deployment Status. This applies the security context to all telemetry from that host.DT_TAGS:"dt.security_context=<value>" as an environment variable on the process. This scopes the security context to that specific process.dt.security_context via Kubernetes metadata enrichment. This applies to all telemetry originating from that namespace.dt.security_context as a resource attribute in OTEL_RESOURCE_ATTRIBUTES or via the OpenTelemetry Collector.Where telemetry is collected via Dynatrace components (OneAgent, cloud integrations, Dynatrace Operator), configure the dt.security_context field in the central primary Grail tag configuration under Settings > Collect and capture. This ensures that all components apply a consistent mapping at source.
Within this configuration, you can:
dt.security_context.environment=prod).Where further refinement is needed beyond at-source enrichment, define dt.security_context in OpenPipeline using dedicated Set security context processors. These are available for spans, logs, and metrics.
In OpenPipeline, you can derive dt.security_context from any combination of primary Grail fields, primary Grail tags, and other incoming attributes. This is useful when the security context value needs to be computed or transformed from multiple source fields.
Dynatrace provides signal-specific guides for configuring security context and Grail permissions: