For the purposes of this post, when I'm talking about granting access with the new IAM capabilities I'm going to focus only on the new platform capability. So things like classic cloud integrations or extensions that haven't been updated to a Smartscape on Grail compatible version don't apply here.
Management zones are dead, long live management zones?
While it is true that management zones are not the way we manage access in the new Dynatrace platform, the way we think about access does not have to change too much. With a management zone, if you included an entity in one you would give access to all data effectively coming from that entity. With the new IAM boundaries, you can achieve a very similar thing.
Lets say you want to give access to everything within a specific K8s namespace.
- With a management zone, you would create rules that included all entities in that namespace.
- With the new IAM boundaries, you would create a boundary that restricts storage access to a specific namespace.
The 2 approaches sound very similar, so what is actually different? Management zones as mentioned were entity focused. You would give access to an entity and by extension the data associated with it. New IAM boundaries are record focused. You give access to individual records based on fields attached to them.
With the IAM boundary example above, that boundary would look as simple as:
storage:k8s.namespace.name MATCH ('NamespaceNameHere');
Combine this with a policy that provides access to all tables and this boundary would restrict access to only data where the k8s.namespace.name fields equals NamespaceNameHere.
The last thing to mention here is that you may be thinking "but when I look in the data explorer, none of my metrics have these fields so how will this work?!" and you'd be right! In the classic Dynatrace, things like Service metrics had 1 dimension, the Service entity. However if you hop into a notebook and query the same metric you'll find an explosion of dimensions, and you'll also start to see a pattern of dimensions consistent across many different metrics.
Grail Primary Fields
In the new Dynatrace platform there are what we call "Primary Grail Fields" and these are a set of fields consistent across all data ingested into Dynatrace. The best way I like to view them is through the IAM policy reference doc https://docs.dynatrace.com/docs/shortlink/iam-policystatements#storage which is a very very dry read. It is however my best friend when it comes to navigating the murky IAM waters. The link I provided takes you to the section specific to storage, and what you will find there is that the conditions you can apply to access all of the different storage tables are very similar. Some have different fields you can use but most, if not all, share a base set of fields. They are:
storage:bucket-name, storage:k8s.namespace.name, storage:k8s.cluster.name, storage:host.name, storage:dt.host_group.id, storage:dt.security_context, storage:gcp.project.id, storage:aws.account.id, storage:azure.subscription, storage:azure.resource.group, storage:frontend.name
Where possible Dynatrace will attempt to enrich all data ingested with these fields. This means that you can use these fields to build out your boundaries. These fields are great for building out boundaries as they often already represent boundaries within an environment.
Now, there are some exceptions, for example Extensions don't just magically get these fields filled in, however when setting up an extension configuration you are prompted with the ability to provide values for these fields. And with synthetics, they rely on the security context field.
How I approach IAM
The first thing I do when building out an IAM approach is nail down a host group and security context naming structure. If you can develop a solid security context structure, this can solve 99% of access problems. For example, if I build a security context structure that is something like:
{app}-{stage}-{function}
When filled in that might look like:
Store-Production-Cart
Store-Staging-Database
API-Dev-Gateway
So if this security context is applied on my OneAgents, in my Kubernetes environments, in my cloud, I can build boundaries such as:
storage:dt.security_context MATCH ('API-*'); This gives access to the whole API app
storage:dt.security_context MATCH ('Store-Production-*'); This gives access to the Store Production environment
For small environments, or ones that aren't very complex, you can get away with not using the security context field at all and instead rely solely on primary grail fields. Regardless, once I have that naming convention set the approach I currently use is to build a matrix of the teams and their boundaries. It looks something like:
| Team Name | Azure Sub | AWS account | Host group | K8s cluster | K8s namespace | SecurityContext | Frontend |
| Store Ops | 12345
67890 | N/A | Store-* | Store-Cluster-* | N/A | Store-* | Store-* |
| Store Dev | 67890 | N/A | Store-Dev-* | Store-Cluster-Dev | N/A | Store-Dev-* | Store-Dev |
You may not need to list out all teams, as some may have overlap, or the access restrictions may not need to be so strict. The point of this matrix though is to very simply go through and define what it is each team is allowed to see. We can then very simply turn each of these columns into a boundary.
If we take Store Ops as an example we would create 5 boundaries, one for their subscriptions, one for their host groups, one for their clusters, one for their security contexts and one for their frontend.
The original questions
- What is the recommended attribute to build Policy Boundaries on?
Grail primary fields - Are you using tags, custom attributes, security context, Kubernetes metadata, or something else?
If you look at the IAM policy reference doc I shared, at the moment only the fields listed there can be used for access control. So tags and custom attributes can not. However they are incredibly useful for segments so don't abandon them. - How do you ensure a consistent restriction across logs, traces, metrics, and entities?
Since Grail primary fields are consistent across all data types, this is how I ensure consistency - Are Segments part of your access-control strategy, or do you use them only for navigation and filtering?
They are not part of my access control strategies as they cannot be used for access control. However if you build out solid naming conventions and consistently apply primary grail tags across the environment, segments can be a much more powerful way of doing filtering vs management zones. There are default set based on the primary grail fields to get you started!
I think the above is a great way to approach IAM. You may find you need to control access to specific metrics, or all data except spans, or even limit access to specific fields. These are also all possible now, but before diving into the crazy convoluted topics, building that foundation is so important. It prevents things from getting out of hand.
Hopefully the above helps!
