Policy Schemas now allowing extra access

[ChadTurner]

So previously our policy schemas were allowing us the ability to DENY certain access on certain settings of the product. We have the policy schema set to DENY Alert Profiles and Alert integrations, but with our test user account, the users now have access. 

We really cant be setting policies only to have them be rendered ineffective after a random cluster update.  We had original set this deny back in cluster version 1.227 and validated that very thing was working prior to the new cluster 232 being posted. 

We are running on cluster:  1.232.98.20220113-164113 - SaaS 

[kparrish]

This is always my concern with Dynatrace..  We have encountered a number of issues with cluster upgrades. One bug in code releases can cause problems for customer facing applications.  I believe the testing process should be reviewed  . 

[apasoquen1]

As with any cluster update, it should not CAUSE loss of functionality.   Besides policy based permissioned, true AD integration would be a welcomed.

[NRH]

We are currently running into this issue as well. While DENY rules are not officially supported in the documentation, they offer tons of flexibility in customizing security policies for different groups. There seems to be some discrepancy with whatever implicit DENY Dynatrace is using because I think it's undesirable that certain features (integrations, alerting profiles, et al.) are being granted by default.

We want to be able to give our users the flexibility and autonomy they need to make changes to settings at the entity-level for entities in their respective Management Zones while also being able to grant them a handful of select features from the global settings. The Settings 2.0 model is a fantastic idea and step in the right direction, but the lack of flexibility is a huge pain point.