- last edited on by
MaciejNeumann
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!
Featured Posts
