Set up Grail permissions for logs

  • Latest Dynatrace
  • How-to guide
  • 4-min read

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:

  • dt.host_group.id
  • 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.

This enables you to set additional options, for example, permissions for individual records. For details, see Permissions in Grail.

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 security context for logs in OpenPipeline

Let's assume that your log records contain the log.source attribute with the payment-api value and only certain users or user groups should have access these log records.

To create a security context adjustment for your ingested log data, create a processing rule that:

  • Processes all records where the log.source attribute value is payment-api.
  • Adds a dt.security_context attribute with the sec-lvl-7 value.

To configure the processor in OpenPipeline

  1. Go to Settings Settings > Process and contextualize > OpenPipeline > Logs.
  2. Find an existing pipeline or create a new one.
  3. Go to the Permission tab.
  4. Select Processor > Set security context.
  5. For Name, enter Level 7 - payment-api.
  6. Set the Matching condition to matchesValue(log.source, "payment-api").
  7. Configure the processor. Set Security context value to Static string, and then set the value to sec-lvl-7.
  8. Save the pipeline.

Once new log data arrives, it's processed by log security context rules and a new dt.security_context attribute is added with the sec-lvl-7 value. Go to Logs Logs: to check whether new log records are processed by your Level 7 - payment-api log security context rule. Filter for logs with the dt.security_context field equal to sec-lvl-7.

Based on this attribute, you can now create security-related user and group policies. For additional information, see Configure advanced permissions with security context.

Related tags
Log Analytics