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.idhost.namek8s.cluster.namek8s.namespace.nameDynatrace provides a comprehensive permission model for Grail that applies to all telemetry data-including metrics, logs, spans, and events.
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.
To add the security context to your OpenTelemetry data, enrich your signals with the dt.security_context attribute. Dynatrace automatically propagates the dt.security_context value from spans to the service entity for span data.
You can use your existing labels and tags to facilitate permissions in Dynatrace:
You can use Kubernetes labels or annotations as a source for your dt.security_context. This is one of the most convenient ways of doing this.
Alternatively, you can configure the OpenTelemetry Collector to enrich data in transit. If you do this, you might have to map your Kubernetes metadata to dt.security_context in OpenPipeline.
To use the OTEL_RESOURCE_ATTRIBUTES environment variable, just directly set the dt.security_context as a resource attribute. You can also use any resource attribute in OpenPioeline as a source for your dt.security_context.
Dynatrace OneAgent provides enrichment files or environment variables to add attributes directly in your application code.
To read more about enrichment options and setup, see how to enrich via environment variable.