This article shows you how to set the security context and grant access to the monitored entities using policies.
Don't mistake IAM policies with management zones. Unlike management zones, an IAM policy that is set up to filter entities (allow storage:entity:read
) will not filter related metrics, logs, or traces.
These entity filters only control which entities can be queried via DQL.
To control access to logs, metrics, and spans, you need to use the corresponding permissions, such as allow storage:logs:read
.
This is for Dynatrace account administrators who are responsible for creating policies to grant users access to monitored entities such as hosts, through DQL.
In this article, you'll learn:
Defines the scope of access for a user or group
Information-partitioning mechanism that promotes collaboration and the sharing of relevant data in your Dynatrace environment
Let’s start by setting up the context, then learn how to create the policies to grant access to data on entities.
The security context field for entities is multi-value. To set the security context for entities, you can choose one of the following options,
Set the security context via the Monitored entities API. If the security context name is identical to the name of an existing management zone, all the matching entities will be assigned to the management zone. This helps you migrate your current management zones to the security context.
Map it to an already existing property (based on its type). Supported values are entity.detected_name
and managementZones
.
Go to Settings > Topology model > Grail Security Context.
In the Destination property section, choose the preferred entity and expand for details.
For generic entity types, you can add an extraction rule for dt.security_context
and derive the security context from any detail on the data source. Let's take a look at the following example:
my.dummy_metric,name="Dummy Name 1",id=1,context="Security Context 1" 42my.dummy_metric,name="Dummy Name 2",id=2,context="Security Context 2" 42my.dummy_metric,name="Dummy Name 3",id=3,context="Security Context 3" 42my.dummy_metric,name="Dummy Name 4",id=4,context="Security Context 4" 42
Then, you can extract an entity using metrics as the ingest datasource type and the metric ID.
Based on this, you can create an attribute by creating an extraction rule that sets the dt.security_context
to the value of the context
variable appearing in the payload.
You can set the security context using the dt.security_context
host property set using automated rules or host properties set using OneAgent configuration via command-line interface.
Tags assigned through environment variables or Topology and Smartscape API can't be used to set the security context.
After you set the security context on a host, it will be used to automatically determine the security context for all logs, spans, metrics, and events that are sent from this host.
Additionally, it will set the security context for all entities reported from this host, such as process group instances and hosts.
To set a security context using oneagentctl
:
./oneagentctl --set-host-property=dt.security_context=my-security-context
Entity permissions allow you to define policies that control data access on entities. In contrast to monitoring data, entity permissions only allow filtering for the dt.security_context
field.
Access to all entities is configured via the storage:entities:read
permission, which supports the following conditions
storage:entity.type
the entity type in upper snake case (for example PROCESS_GROUP_INSTANCE
)
storage:dt.security_context
the security context of this entity. Can be a multi-value field and startsWith
will evaluate for any matching value.
For example, the following policy grants access to data with the security context set to mySecurityContext
.
ALLOWstorage:entities:readWHEREstorage:dt.security_context = "mySecurityContext";