With the introduction of Smartscape in Latest Dynatrace, there are changes in how settings objects are scoped to monitored entities. This affects how security policies are applied, and how to grant modification access.
This page describes how to update your security policies for scoped settings objects, to ensure that they continue to work in Latest Dynatrace.
These changes affect how:
This update does not affect the functionality of IAM policies or automations themselves.
Read and write access for IAM policies, granted either
iam:policies:read and iam:policies:write IAM permissions.Full access to read Smartscape data: you need the storage:smartscape:read IAM permission.
This permission is included in the Standard User policy, so you'll probably also have it.
This is a breaking change for both grant and restriction policies:
ALLOW statements stop granting access. Users who previously had access through a management zone or entity scope condition lose that access.DENY statements stop blocking access. Restrictions that relied on these conditions no longer take effect, which can unintentionally widen access.Review your IAM policies and any automation that reads or writes scoped settings objects before this change reaches your environment.
Audit every policy that uses these conditions, and migrate the policy to use a condition that remains valid after the transition.
Update any IAM policy condition and any environment API call that references a host group by its entity ID, so it uses the host group's string-based identifier instead.
Until enrichment is extended to all Smartscape nodes, do not rely only on security-context conditions to grant or restrict access to settings objects whose security context is not set at the edge.
Management zones have been discontinued as part of the Smartscape transition. As a result, IAM conditions that depend on management zones, or on scope identifiers derived from monitored entities, no longer match the affected settings objects. This includes:
environment:management-zone). Because management zones no longer exist, these conditions never match.settings:scope conditions that reference an entity-based scope identifier.Examples:
A statement that is affected and must be reviewed:
// Affected: management-zone condition no longer matches after the transitionALLOW settings:objects:read, settings:objects:writeWHERE environment:management-zone = "Production";
A condition that remains valid:
// Scope access by schema instead of by management zoneALLOW settings:objects:read, settings:objects:writeWHERE settings:schemaId = "builtin:alerting.profile";
Host groups no longer have an entity ID. They must be addressed by their string-based identifier (for example, datacenter-west) on both the environment API and in IAM policy conditions.
Examples:
Invalid IAM policy condition:
// No longer valid: entity-ID-based host group scopeALLOW settings:objects:read, settings:objects:writeWHERE settings:scope = "HOST_GROUP-8555E20A1152D99E";
Valid IAM policy condition:
// Valid: string-based host group identifierALLOW settings:objects:read, settings:objects:writeWHERE settings:scope = "dt.host_group.id:datacenter-west";
The settings:entity.hostGroup IAM condition continues to work unchanged, with the same behavior as before. It applies both to the settings of the hosts belonging to the host group and to the host group settings itself.
ALLOW settings:objects:read, settings:objects:writeWHERE settings:entity.hostGroup = "mygroup";
Make sure that other entity IDs are valid in your Dynatrace environment.
If any entity IDs are invalid, you will need to update how your policies address these entities, for example with settings:schemaId or the string-based identifier.
To do this, verify explicit node references by querying Smartscape with DQL. The query below shows how to search for the entity ID based on the string-based identifier (in the placeholder).
smartscapeNodes "*"| filter id_classic == "<the-old-scope-identifier>"
Security context enrichment is initially available only for values that are set at the edge, for example when ingesting via OneAgent. Therefore, if you want IAM conditions to match based on security context, security context must be set at the edge.
A security-context condition will not match for nodes that are not yet enriched:
ALLOW statements based on the security context do not grant access for those nodes.DENY statements based on the security context do not block access for those nodes.Example of a valid security context condition:
ALLOW settings:objects:read, settings:objects:writeWHERE settings:dt.security_context = "restricted";
Settings objects whose security context is expected to be derived elsewhere are not enriched in this phase. Enrichment for all Smartscape nodes is planned for a later phase.