Restrict metric access via IAM policy

[andre_vdveen]

Hi, is it possible to restrict user access to specific metrics via IAM policies? Based on the documentation, specifically the storage:metric.key, it seems it is, but I'm curious if anyone's done it before and if so, what would the syntax look like?

The client wants to restrict access to e.g., Azure firewall metrics so that only certain people can see them and the datapoints.

Thanks in advance,
André

[PacoPorro]

Please check the ABAC approach in the documentation.
https://docs.dynatrace.com/docs/manage/identity-access-management/permission-management/manage-user-...

The overall idea is to apply a boundary to a policy.

https://docs.dynatrace.com/docs/manage/identity-access-management/permission-management/manage-user-...

[andre_vdveen]

Thanks @PacoPorro, I reviewed the docs before posting here 😉
The config I applied doesn't seem to work in my case, hence me hoping for an example or someone confirming it is actually possible to do it for specific metrics 🙂

Here's my policy and boundary syntax, perhaps I'm doing it wrong? I've applied the policy and boundary to my group, and added the user to the group.

Policy: ALLOW storage:metrics:read WHERE storage:metric.key='fragmentation.percentage';
Boundary: storage:metric.key='fragmentation.percentage';

[DanielS]

Hi @andre_vdveen I copy an example of what I have configured and it is working as expected. Hope it helps you.

[andre_vdveen]

Hi @DanielS thanks for sharing.

I've set it up exactly as you have it there in the screenshots, and applied the policy to my group, then added my user to the group (allow access) and made sure my other user (test user, no access) is not in that group, but the test user still has access to the metric 😞

I must be doing something wrong here, clearly...

[PacoPorro]

Is it possible that the test user has unrestricted access to the metric storage?

[andre_vdveen]

Most likely, yes but I thought custom metrics like in my case, would not fall under the scope for a user that is only a member of the 'Monitoring viewer' group, no other.

[DanielS]

Look, @andre_vdveen This is a test group, same policy as previous post, and if I remove everything except the monitoring viewer and keep/remove metrics permissions, the user loses or gains access.

[andre_vdveen]

Thanks @DanielS, does that work in the Data Explorer too though? I think that's where the difference comes in, I was looking there 😉

I've tested it again via Notebooks and it works as you've explained...yet in Data Explorer, the user can still see and access the metric. That's a bit of a problem, since some users who're not yet comfortable with Notebooks, will revert to using Data Explorer and still have access to the metrics they're not supposed to.

[DanielS]

That's right @andre_vdveen for everything under the scope of the Classic Dynatrace I've managed everything with Management Zones and I allow or disallow metrics with the following rules:

Grail data access policies do not work with the classic schema, so during the transition it is necessary to manage both schemas. It may be a bit cumbersome but today we must coexist with both worlds.

[Maheedhar_T]

Hey @andre_vdveen , @DanielS Kind of interesting discussion here.. Never noticed that because I often use DQL even for metrics but have you tried adding that metric to a MZ and then try restricting the user access based on MZs ?
Kind of always works 🙂 or even exploring segments might be a better option as this might replace MZs in far future 😜

[DanielS]

Hi @Maheedhar_T  that's right, for all Dynatrace Classic, working with MZ is the way to restrict access. But under the scope of the Latest Dynatrace, the approach is different.  Thanks for joining the discussion.

[Maheedhar_T]

Yeah @DanielS ,
Agreed. That's where using segments would be an alternative approach but again, we have to come back to using IAM to control the access of segments too.