Permissions in Grail

Permissions can be assigned on the bucket, table, and entity levels. Without permissions, your users can't fetch any data from a bucket or table.

Bucket and table permissions logic

Set up permissions

To set up the bucket and table-level permissions

Go to Account Management. If you have more than one account, select the account you want to manage.
Go to Identity & access management > Policies.
Select Create policy.
Add the policy details:
- Name
- Description
- Policy statement—use the following format:
```
ALLOW <bucket permission> where <condition>;
ALLOW <table permission>;
```
See below for supported bucket and table permissions.
Select Create policy.

Bucket permissions

All bucket permissions need to start with storage:buckets:read. Their scope can be limited by a WHERE clause that includes one of the three operators:

= (equals), indicating an exact match.
STARTSWITH with an expression put in quotation marks.
IN, indicating a range.

After the WHERE clause, you can filter your stored buckets by a specific bucket name or a defined table name:

WHERE storage:bucket-name
WHERE storage:table-name

For more information, see IAM service reference.

Table permissions

All tables related to log monitoring have their corresponding permissions that need to be set.

Table name	Permission
logs	storage:logs:read
events	storage:events:read
metrics	storage:metrics:read
bizevents	storage:bizevents:read
spans	storage:spans:read
entities	storage:entities:read
dt.system.events	storage:system:read

For more information, see IAM service reference.

Record permissions

You can define fine-grained permissions for records that are stored in Grail. The permissions are added to the existing table permissions by adding the WHERE clause. For example:

ALLOW storage:logs:read WHERE storage:dt.security_context="TeamA";

Supported fields:

Field name	IAM condition	Supported IAM tables
`event.kind`	`storage:event.kind`	`events`, `bizevents`, `system`
`event.type`	`storage:event.type`	`events`, `bizevents`, `system`
`event.provider`	`storage:event.provider`	`events`, `bizevents`, `system`
`k8s.namespace.name`	`storage:k8s.namespace.name`	`events`, `bizevents`, `logs`, `metrics`, `spans`
`k8s.cluster.name`	`storage:k8s.cluster.name`	`events`, `bizevents`, `logs`, `metrics`, `spans`
`host.name`	`storage:host.name`	`events`, `bizevents`, `logs`, `metrics`, `spans`
`dt.host_group.id`	`storage:dt.host_group.id`	`events`, `bizevents`, `logs`, `metrics`, `spans`
`metric.key`	`storage:metric.key`	`metrics`
`log.source`	`storage:log.source`	`logs`
`dt.security_context`	`storage:dt.security_context`	`events`, `bizevents`, `system`, `logs`, `metrics`, `spans`, `entities`
`gcp.project.id`	`storage:gcp.project.id`	`events`, `bizevents`, `logs`, `metrics`, `spans`
`aws.account.id`	`storage:aws.account.id`	`events`, `bizevents`, `logs`, `metrics`, `spans`
`azure.subscription`	`storage:azure.subscription`	`events`, `bizevents`, `logs`, `metrics`, `spans`
`azure.resource.group`	`storage:azure.resource.group`	`events`, `bizevents`, `logs`, `metrics`, `spans`

For details that are not available as a dedicated field, set the dt.security_context field either at the data source or in the processing pipeline.

As a Dynatrace administrator, I would like to ensure that each of my application teams can only access logs from their own Kubernetes namespace (records identifiable through k8s.namespace.name) and logs that belong to the basic infrastructure (records identifiable through dt.host_group.id).

Solution:

Create a policy for each team that grants them access to their logs.

Make sure that the user has access to all relevant buckets.

ALLOW storage:buckets:read WHERE … // Ensure that the user has access to all relevant buckets
ALLOW storage:logs:read WHERE storage:k8s.namespace.name="namespace1";
ALLOW storage:logs:read WHERE storage:dt.host_group.id STARTSWITH "shared_host_";

As a Dynatrace administrator, I would like to set up access for my application teams to access logs from lambda functions based on the team tag. For example team = A.

Solution:

Define the log processing rule with a security context that adds the dt.security_context field based on the lambda tag.

Create a policy for each team that grants them access based on the security context field.

Make sure that the user has access to all relevant buckets.

ALLOW storage:buckets:read WHERE … // Ensure that the user has access to all relevant buckets
ALLOW storage:logs:read WHERE storage:dt.security_context="TeamA";

As an administrator, I want to control access to business events that contain financial data. They can be identified using the event.type field.

Solution:

Create a policy to grant access for specific users to records in bizevents for the specific event.type (Opportunity Field History).

Make sure that the user has access to all relevant buckets.

ALLOW storage:buckets:read WHERE … // Ensure that the user has access to all relevant buckets
ALLOW storage:bizevents:read WHERE storage:event.kind="Opportunity Field History";

As an administrator, I want to provide selected users access to billing events but not to any other system events.

Solution:

Create a policy to grant access to records in dt_system_events for the specific event.type with the value BILLING_EVENT.

ALLOW storage:buckets:read WHERE storage:bucket-name="dt_system_events"
ALLOW storage:system:read WHERE storage:event.kind="BILLING_EVENT"

Record permission limits

The following configuration limitations apply to record permissions:

Number of statements per policy (100)
Number of policies per account (200)

Record permissions for entities

Record permissions for entities allow you to define IAM policies that control data access on entities. In contrast to monitoring data, entity permissions only allow filtering for the dt.security_context field.

Set the security context for monitored entities

The security context field for entities is multi-value. To set the security context for entities, you can:

Set the security context via API.
Map it to an already existing property (based on its type). Supported values are entity.detected_name and managementZones.
1. Go to Settings > Topology model > Grail Security Context.
2. Choose the preferred entity and expand for details, where you'll find the Destination property section.
Define an extraction rule for generic entities.

Field permissions

You can use field permissions to hide fields that might contain sensitive data. For this purpose, Dynatrace provides fieldsets. A field is considered sensitive when it's part of a fieldset. Once a field is part of a fieldset, you can't use it in DQL queries for filtering and grouping, and it won't show up in the query results.

You require permission to access the fieldset in order to read sensitive fields. For example, if you want to read builtin-sensitive-spans fields, you need the following permission:

ALLOW storage:fieldsets:read WHERE storage:fieldset-name="builtin-sensitive-spans"

The existing fieldsets are:

builtin-sensitive-spans - drops all fields on spans that are considered sensitive
builtin-request-attributes-spans - drops all fields on spans that contain request attribute data that was marked sensitive

You can't define your own fieldsets.
The two predefined fieldsets apply to spans only. They don't apply to logs or events.
If you don't have sufficient permissions, Grail displays a message about missing fields in the query result.

Predefined global policies

There are several predefined global policies, each set per table (logs, events, bizevents, security events, metrics, entities, spans), and three additional, general policies:

Read all data
Read default monitoring data
Read all system data

Access to all logs

This policy provides access to all logs from Grail, and narrows the bucket permission with a WHERE condition that limits the results to the log table.

This statement provides access to all built-in and custom buckets.

ALLOW storage:buckets:read WHERE storage:table-name= "logs";
ALLOW storage:logs:read;

Read all data

This permission statement gives you access to all tables and all buckets, therefore it needs to be used only in justified cases.

ALLOW storage:buckets:read;
ALLOW storage:system:read,
      storage:events:read,
      storage:logs:read,
      storage:metrics:read,
      storage:entities:read,
      storage:bizevents:read,
      storage:spans:read;

Read all default monitoring data

This policy retrieves all default monitoring data.

In the first line, this policy statement gives access to all default buckets. The WHERE condition narrows the search to buckets whose name starts with default. Subsequently, the next lines list all the needed table permissions.

This statement does not give access to custom buckets.

ALLOW storage:buckets:read WHERE storage:bucket-name STARTSWITH "default_";
ALLOW storage:events:read,
      storage:logs:read,
      storage:metrics:read,
      storage:entities:read,
      storage:bizevents:read,
      storage:spans:read;

Read all system data

This permission statement first narrows the results to system buckets, whose name starts with dt. Then, it gives you access to all tables that contain system data, for example audit events, billing events, and query execution events. It can be useful for system admins.

ALLOW storage:buckets:read WHERE storage:bucket-name STARTSWITH "dt_";
ALLOW storage:system:read;

Best practices

Ensure that you also have bucket permissions.
If there is an unconditional table permission in any other policy available for a user, the WHERE clause is irrelevant and the user will always be able to view all records from that table.
Make sure to use the IN keyword if you are testing for different values. For example
```
ALLOW storage:logs:read WHERE storage:dt.k8s.namepsace.name IN ("ns1", "ns2")
```
This is important because there is a 100-statement limit per policy - IAM policy statement syntax and examples
Make sure to use the STARTSWITH command if there are more than one values that start with the same substring.
Make sure to combine logs, events and metrics where applicable (to further save on the 100 statement policy IAM policy statement syntax and examples)

Permissions in Grail

Set up permissions

Bucket permissions

Table permissions

Record permissions

Record permission limits

Record permissions for entities

Set the security context for monitored entities

Field permissions

Predefined global policies

Access to all logs

Read all data

Read all default monitoring data

Read all system data

Best practices

Related topics