Showing results for 
Show  only  | Search instead for 
Did you mean: 

PRO TIP - Leveraging Binding Policies for Granular User Permissions for Self Service

DynaMight Legend
DynaMight Legend

Over the last few years our customers have been asking for a self service solution. At the end of the day, they want the ability to edit, adjust and configure their alerting profiles, integrations thresholds and more when it comes to the apps they support. They no longer want to put in a Support request to have a maintenance window set, they want to do it themselves! 


Dynatrace has been working towards a solution for this and as more and more cluster updates arrive, so do the granular permission capabilities. 


To set these permissions you need to be an admin, and keep in mind this guide is based off the SaaS Platform and might be different for Managed. 


Step One: 

Make a test group within the accounts section of your Dynatrace Instance. This is something that you might already be familiar with. So lets create one, I'll call it "Community Test" Within the Accounts page, Select the "Identity Management" then "Group Management" and select "Add Group": 



Step Two: 

Now we need to start building Policies to bind to this group. To do this, Navigate to the "Policy Management" within the Identity Management Section and select "Add Policy":



Notice the Organization Level, this is the level that your policy will apply to. "Account" will be rules that can be bound to the Account Level, Which is permissions that Admins typically have to Access Account, Manage Users and Edit Billing & Account Info. I'm going to select our NP environment for this use case. 


Lastly on this page we need to add in the Policy Statements. For the statements you will need the ScheamaID. Which can be pulled via API. So If you picked NP like I did, go into your NP Dynatrace environment and open up the Environment V2 API:



Have your API Token handy and select the Get Schemas. This will give you a list of all the Schemas, the other get will provide you with a description of a given Schema. 



Keep in mind, Dynatrace keeps adding more schemas as cluster updates roll out. So you might want to always pull the newest schemas available to you. Toss them into your tool of choice like NotePad++. 


Now that we have the Schemas, we can jump back to the Policy that we were working on and start our Statements!


These statements can be tricky. I've found that you can use Allow and Deny, to grant or remove access. I recommend using the following Statement Templates: 


DENY settings:schemas:read, settings:objects:write WHERE settings:schemaId = "{Schema ID}";


ALLOW settings:objects:read, settings:objects:write, settings:schemas:read WHERE settings:schemaId = "{Schema ID}";


Step 3 

Set your Statements. For this I will be using only one statement to showcase the functionality of the binded Policies. 


I'm using the following statement: 

ALLOW settings:objects:read, settings:objects:write, settings:schemas:read WHERE settings:schemaId = "builtin:monitoring.slo"; 




Step 4:

Now we need to Bind this Policy to our New Group. So Edit your Group, and scroll down to environment Permissions and select Policies. As of today, this is the lowest level you can go. But If you are leveraging Management Zones we have a little trick. 



Now that the Policy is bound, Lets Scroll down and select the Management Zone(s) you want the users to have access to: 


 You can check the boxes as needed but what's required is the change monitoring settings. What will happen is that the Binded Policy one level above, will override the change access and we will sow case that soon. 


So now we have created a Group, built a Policy with the Schema we wanted, (SLO) and now we have just bound the policy to the Group, and selected the Management Zone(s) the users would need access to.  The last part is setting the user. If your organization allows you to have a Test account, use that one. If not, maybe ask a fellow co worker if you can edit their permissions for testing. 


Step 5: 

So now I have edited our test account, and assigned the new Group we made, Community Test, to the account. Now we are all set! Lets take a look at what the user can see! 


Now from the UI Main page of the Test Account, we can see Settings as an option on the left hand Menu. Clicking into the settings we can see the following: 



And the user has access to Host, Process, Services, Applications settings as well where they can change alert thresholds as they see fit. 



As we showed in the other screen capture, there was Alerting and Integration Available in the Environment Settings page. This is where the DENY comes into play. So copy these two Statements: 


DENY settings:schemas:read, settings:objects:write WHERE settings:schemaId = "builtin:alerting.profile";
DENY settings:schemas:read, settings:objects:write WHERE settings:schemaId = "builtin:problem.notifications";


And lets paste them into the Policy we had created: 


So now I have my Two Denys, and my One allow for SLO. Lets log out and log back in and see what the User sees: 



Notice how there is only one settings option, the SLO one. But the user still has the same functionality at the host level as shown before. These Policies ONLY Apply at the Environment Level. Hopefully soon Dynatrace expands this down to the Management Zone Level. 


I hope this helps! 



DynaMight Champion
DynaMight Champion

@ChadTurner - Huge help! I was just starting to look into this. Thank you! 👍

@larry_roberts feel free to add in any additional tips or tricks that you come across! 



This is something I've played around with a bit but the sections within the settings that we want to give our users access to, is not there yet. We would love to give at read only access to custom events and the ability to create your own maint windows but those schemas are not there yet last I checked few weeks ago. The concept of policies is great addition but there isn't much useful schemas yet for us.


Flexibility in giving rights/roles to at a granular level is a welcome development.


The ability to go granular in giving rights/roles on monitoring setting will go a long way in driving adoption of the the tool to different levels of Engineers.



The ability to go granular in giving rights/roles on monitoring setting will go a long way in driving adoption of the the tool to different levels of Engineers.


Hi Chad, 

Thanks for putting this together. Very helpful.

Yes, it's a very useful feature in the right direction when it's fully developed. 

I will have to wait until the feature supports management zones (MZ). 

Due to lack of granular access management at MZ level, my team and I are forced to perform certain tasks which otherwise will be the responsibility of applications folks/developers.


A recent addition to have MZ scoped maintenance windows (not via IAM policy) was a good thing.

Thanks. Tibebe  

Dynatrace Advisor
Dynatrace Advisor

Thanks @ChadTurner  !
For info and update it is already there also in Managed 🙂 
User authentication > Policy management.

DynaMight Pro
DynaMight Pro

These ones would work right?

Policy name: Maintenance window Reader
Policy description: 
Permisson to view (read) alerting maintenance window configuration
Policy statements:
ALLOW settings:objects:read, settings:schemas:read WHERE settings:schemaId = "builtin:alerting.maintenance-window";

Policy name: Maintenance window Writer
Policy description: 
Permisson to modify (write) alerting maintenance window configuration
Policy statements:
ALLOW settings:objects:read, settings:objects:write, settings:schemas:read WHERE settings:schemaId = "builtin:alerting.maintenance-window";

Kind regards, Frans Stekelenburg                 Certified Dynatrace Associate |, Dynatrace Partner

Hi @fstekelenburg 
Normally yes. 
For information, in addition, we can also further limit read and write access via policies. For example by adding the Management Zone into the statement as following : 
ALLOW settings:schemas:read WHERE settings:schemaId ="builtin:alerting.maintenance-window" ;
ALLOW settings:objects:read, settings:objects:write
WHERE settings.schemaId ="builtin:alerting.maintenance-window" AND environment:management-zone="...";
IAM service reference - Dynatrace Docs

Note that here we have splitted the ALLOW statements because the schema:read does not support the management zone condition.

Featured Posts