Set up Grail permissions for Log

Overview
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, 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.

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

To create a security context adjustment to your ingested log data, you need to create rules that:

Filter the records that have the dt.security_context attribute added to them.
Go to Logs and events page and create a DQL query using a log processing function. For example:
```
fetch logs
| filter matchesValue(log.source, "dsfm")
```
This allows you to filter the log records to which you will want to add the dt.security_context attribute. Once satisfied with the query result, copy the log processing function of the DQL query: matchesValue(log.source, "dsfm").
Define the log security context rule using that function and specify the value of the dt.security_context attribute. The value of the dt.security_context attribute can be a literal value that you provide, or you can specify the name of another attribute of which the value will be used as the value of dt.security_context.

Create Log Security Context rule

Log Security Context is based on rules that contain a matcher and the dt.security_context attribute definition.

The matcher narrows down the available log records for executing this specific rule.
Value source type specifies the value of the dt.security_context attribute.

Go to Settings > Log Monitoring > Security context to view log processing security rules that are in effect, reorder the existing rules, and create new rules. Rules are executed in the order in which they're listed, from top to bottom. This order is critical because the first user-defined rule that matches is executed.

Expand Details to examine a rule definition. A log processing security rule consists of the following:

Rule name
The name for the rule.
Matcher
A log processing function that narrows down the available log data for executing this specific rule.
Select value source type
- Field
  Value will be copied from field.
- Literal
  Constant literal will be used as value.
Value
Value of the source type.

To add a log security context rule:

Select Add rule on the Log Security Context page.
Add a Matcher to your rule by pasting the log processing function from your DQL query.
Select value source type.
Provide the Value for the source type.
- If you selected Field, the value should be the name of the field used as a source to copy the value to the dt.security_context attribute.
- If you selected Literal, the value should be the constant literal that will be used as the value in the dt.security_context attribute.

Example

Your log records contain attribute log.source with a value of dsfm. Only certain users or user groups should have access to them and you want to create a log security context rule that:

Filters all records that contain dsfm as a value of the log.source attribute.
Adds a dt.security_context attribute with the sec-lvl-7 value to all filtered log records.

Go to Logs and events page and execute a DQL query using a log processing function:
```
fetch logs
| filter matchesValue(log.source, "dsfm")
```
Copy the log processing function of the DQL query: matchesValue(log.source, "dsfm").
Go to Settings > Log Monitoring > Security context and select Add rule on the Log Security Context page.
For the Rule name enter: Level 7 - dsfm.
For the Matcher enter: matchesValue(log.source, "dsfm").
For the Select value source type select Literal.
For the Value enter: sec-lvl-7.
Select Save changes.

Once new log data arrives, it is processed by log security context rules and a new dt.security_context attribute is added with a value of sec-lvl-7. You can go to Logs and events page and check that new log records are processed by your Level 7 - dsfm log security context rule. Use the DQL to view all log records containing sec-lvl-7 value in dt.security_context attribute:

fetch logs
| filter matchesValue(dt.security_context, "sec-lvl-7")

Based on this attribute, you can now create security-related user and group policies. See, Permissions in Grail.