IAM Policies for New Problems App: Restricting Problem Visibility by Management Zone or Security Context

[anaidu]

Hello Dynatracers,

I'm currently facing a challenge in configuring IAM policies to restrict problem visibility in the New Problems App.

We have a user group, ABC, which is assigned the Standard user policy, and is further restricted by a policy boundary that includes:

• A specific Management Zone (MZ) rule

• A separate Security Context rule

When a user from this ABC group logs in:

• They are able to access the New Problems App, but

• No problems are visible in the app (nor on any dashboard widgets based on the new Problems view)

Interestingly, as soon as we remove the policy boundary, they are able to view all problems — but this is not acceptable, as we don't want users to view problems beyond their relevant MZ.

With the traditional Problems App, the same boundary configuration works as expected — problems are scoped correctly to their MZ.

Our challenge is:

• The New Problems App does not honor the MZ/Security Context restriction in the same way

• Our new dashboards rely on this new Problems view, meaning these restricted users now see nothing

Request: How can we configure IAM policies and boundaries so that:

• Users can view problems in the New Problems App and dashboards

• But only those problems within their assigned Management Zone or Security Context

Is there a supported way to achieve this today? Or a roadmap plan to support MZ-based scoping in the New Problems App similar to the legacy behavior?

Thanks in advance.

[patryk_ozimek]

Hi,

You just need to create a custom IAM policy with the storage:events:read permission.

For example:
ALLOW storage:events:read WHERE storage:dt.security_context = "<value>";

You can find other conditions here: https://docs.dynatrace.com/docs/shortlink/iam-policystatements#storage-events-read

Best Regards
Patryk

[patryk_ozimek]

The whole permissions list is available in DT Hub

[anaidu]

Hi @patryk_ozimek,

Thanks for sharing. We've applied the same configuration using these rules across both events and other storage types, but it's still not working.

[patryk_ozimek]

Are you sure that you have events in grail enabled in your tenant?

Best Regards

Patryk

[Mohamed_Hamdy]

Hello @anaidu ,

I suggest opening a support ticket, as the current behavior doesn't align with what's described in the documentation: https://docs.dynatrace.com/docs/shortlink/iam-policystatements. Some conditions and operators don’t seem to function as expected.

As a temporary workaround—which may not cover all scenarios—you could try creating a separate policy specifically for event access. Be sure to use the condition within the policy itself, not as a boundary.

You can use the dt.host_group.id with the IN operator. For example:

ALLOW storage:events:read WHERE storage:dt.host_group.id IN ("")

This might not fully resolve the issue, but it could serve as a helpful interim step.

[anaidu]

Hello @Mohamed_Hamdy,

Thanks for sharing the workaround, we will use as interim solution till the issue is completely resolved.

[Peter_Youssef]

Hello @anaidu 

In parallel while applying the relevant solutions provided by @Mohamed_Hamdy , @patryk_ozimek , feel free to raise the case as a product idea

KR,

Peter

[J01am]

Hi all ! 
I have the same problem

What I see is that my Problem didn't have a dt.security_context field filled. I tried to apply the documentation here, but the field still keep empty.
Anyone already fix that ? 

Thank you