Best practice for application-level data segregation using Policy Boundaries in Gen3

[andreaCaria]

Hi everyone,

We're currently reviewing our governance model on Dynatrace Platform (Gen3) and I'd be interested to understand how others are handling application-level data segregation.

Our goal is to allow different teams to access only the observability data related to their own application perimeter, including:

• Logs
• Metrics
• Traces
• Events
• Topology entities (services, process groups, hosts, Kubernetes workloads, clusters, etc.)

In the past, with Management Zones, we were able to build a fairly complete segregation model by combining MZs, permissions, and settings scoping. Since we're now moving towards Gen3 capabilities only, that approach is no longer available and we're looking for the recommended replacement pattern.

Some of the questions we're trying to answer are:

• What is the recommended attribute to build Policy Boundaries on?
• Are you using tags, custom attributes, security context, Kubernetes metadata, or something else?
• How do you ensure a consistent restriction across logs, traces, metrics, and entities?
• Are Segments part of your access-control strategy, or do you use them only for navigation and filtering?

Ideally, we'd like to achieve a user experience similar to what Management Zones provided in the past: users belonging to a specific application domain should only be able to see data related to that domain, regardless of whether they are looking at logs, traces, metrics, Smartscape, dashboards, investigations, etc.

I'd be interested to hear how other customers have implemented this and what Dynatrace currently recommends for large shared environments.

Thanks in advance for any suggestions or real-world examples!

[Julius_Loman]

I'd recommend building access control on grail fields and primary tags. This, of course, needs a proper tagging strategy first. Tagging is quite easy with new platforms, but it gets much more complicated for legacy systems, especially shared ones (for example host running multiple different applications for multiple teams, for example a docker swarm cluster). New features such as https://docs.dynatrace.com/docs/shortlink/ingest-enrichment-settings have been introduced recently, which will hopefully make it easier.  Nevertheless, the tagging strategy (what to have in the primary tags/fields) highly depends on your organisation. I recommend reusing existing metadata as much as possible (like k8s labels, for example).

Segments are only for data filtering, you can't really build any access restrictions with them. Boundaries are the way (or policies including conditions).

Some further improvements are being developed, especially for segregation of settings.

[andreaCaria]

Thanks for the explanation.

However, I'm still struggling to see how this would work in practice.

From my tests, Grail tags do not seem to behave like classic auto-tags. For example, I created the following rule:

matchesPhrase(k8s.namespace.name, "sport-coll")

but nothing appears to have been tagged afterwards: neither the namespace itself, nor traces, logs, or events generated from that namespace.

In addition, as far as I can see, Boundary policies cannot currently be filtered using Grail tags, so I'm not sure this would help us implement access segregation.

Could you share a few practical examples of the approach you described?

Our main requirement is to segregate access based on:

• the monitored Kubernetes namespace (for example sport-coll)
• the related frontend application, which should be selected by name (for example SPORT-FE-coll)

In the classic Management Zone model, it was possible to define a perimeter and automatically include the related entities. In the current Gen3 model, we're trying to understand what the recommended equivalent approach is for ensuring consistent access restrictions across logs, traces, metrics, events, Smartscape entities, and frontend monitoring data.

Any example of Boundary policies, primary fields, or tagging strategies used to achieve this would be very helpful.