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

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

ChadTurner
DynaMight Guru
DynaMight Guru

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": 

ChadTurner_0-1633698341193.png

 

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":

ChadTurner_1-1633698590482.png

 

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:

ChadTurner_2-1633699143419.png

 

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. 

ChadTurner_3-1633699345618.png

 

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"; 

 

ChadTurner_11-1633701450209.png

 

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. 

ChadTurner_5-1633700099588.png

 

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

ChadTurner_6-1633700282998.png

 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: 

ChadTurner_7-1633700928810.png

 

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

ChadTurner_8-1633701035782.png

 

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: 

ChadTurner_9-1633701207938.png

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: 

ChadTurner_10-1633701320366.png

 

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! 

 

-Chad
3 REPLIES 3

larry_roberts
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! 

-Chad

travis_anderson
Contributor

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.