Permissions to access the latest version of Dynatrace

[gustavodutra]

Hi everyone.

I'd like to know what permissions I need to grant users to access the latest version of Dynatrace.

Summary:

I have an environment where users need limited viewing. When accessing the tool, they receive the error below and can only use the old version.

The question is: What permissions are required for them to view the new platform?

By clicking on previous Dynatrace, they can use it normally.

[gustavodutra]

Someone? 

[p_devulapalli]

@gustavodutra Have a look at the below, you can start with Standard User and build up on it.

https://docs.dynatrace.com/docs/shortlink/default-policies

https://docs.dynatrace.com/docs/shortlink/default-policies#DynatraceAccessStandardUser

[gustavodutra]

Thanks for the reply. I used "Standard User," but it allows more than they should see.

I'm worried they'll see things I don't want, or they'll create/delete settings or extensions that generate additional costs.

[p_devulapalli]

@gustavodutra You can always create a custom policy with limited permissions , you can limit the permissions to what the end user would need .

You can further restrict by using policy boundaries to limit view to the allowed resources 

https://docs.dynatrace.com/docs/shortlink/iam-policy-boundaries

[tomaxp]

The new views use AppEngine. So the policy:

//Classics
ALLOW environment:roles:viewer,

only grants access to the "old" version of Dynatrace.
You need to add policies like, for example:

//AutomationEngine
ALLOW automation:workflows:read, automation:calendars:read, automation:rules:read;
ALLOW automation:workflows:write WHERE automation:workflow-type = "SIMPLE";
ALLOW automation:workflows:run;

[gustavodutra]

What would this automation engine rule be?

Can they create, view, or delete workflows?

Because this is extremely costly.

[tomaxp]

ALLOW – grants the user/role permission to perform the action.
- automation:workflows:write – this is a specific permission type, meaning the ability to create and edit workflows in the AutomationEngine.
- WHERE automation:workflow-type = "SIMPLE" – a conditional restriction.

It doesn’t grant rights to all workflows.

It only allows writing (creating/editing) workflows that have type = SIMPLE.

 In practice:
A user with this permission cannot create or edit advanced workflows (e.g., ADVANCED or other types), only those marked as SIMPLE.

In your case It’s enough to have only this:
ALLOW app-engine:apps:run, app-engine:functions:run, app-engine:edge-connects:read;

[DanielS]

Hello @gustavodutra a minimum policy for them to access should be:

//States
ALLOW state:app-states:delete, state:app-states:read, state:app-states:write, state:user-app-states:read, state:user-app-states:write, state:user-app-states:delete, state-management:user-app-states:delete, state-management:user-app-states:delete-all;

//Documents
ALLOW document:documents:read, document:documents:write, document:documents:delete, document:environment-shares:read, document:environment-shares:write, document:environment-shares:claim, document:environment-shares:delete, document:direct-shares:read, document:direct-shares:write, document:direct-shares:delete, document:trash.documents:read, document:trash.documents:restore, document:trash.documents:delete;

//Grail
ALLOW storage:bucket-definitions:read;
ALLOW storage:fieldset-definitions:read;
ALLOW storage:filter-segments:read, storage:filter-segments:write, storage:filter-segments:delete;

//AppEngine
ALLOW app-engine:apps:run, app-engine:functions:run, app-engine:edge-connects:read;

//Notifications
ALLOW email:emails:send, notification:self-notifications:read, notification:self-notifications:write, notification:notifications:read, notification:notifications:write;

//Davis
ALLOW davis:analyzers:read, davis:analyzers:execute;

//Davis Copilot
ALLOW davis-copilot:conversations:execute, davis-copilot:nl2dql:execute, davis-copilot:dql2nl:execute, davis-copilot:document-search:execute;

//Settings
ALLOW settings:objects:read, settings:schemas:read, app-settings:objects:read;

//Classics
ALLOW environment:roles:viewer;

//Geolocations
ALLOW geolocation:locations:lookup;

//SLOs
ALLOW slo:slos:read, slo:objective-templates:read;

//BusinessInsights
ALLOW insights:opportunities:read;
ALLOW insights:moments:read;

[gustavodutra]

My users shouldn't be able to view configurations, run them, or save any configuration.

My idea is for them to only have monitoring views of hosts, logs, Kubernetes, etc.

Is there specific documentation that explains what each rule does? Our environment is very critical, and we can't afford any lapses.

I'd like to know if there's a specific rule group that allows for viewing the latest Dynatrace interface.

If so, which ones?

[tomaxp]

// Classic environment and problem view (legacy UI)
ALLOW environment:roles:viewer, environment:roles:view-security-problems;

// Running applications (new interface), without configuration changes
ALLOW app-engine:apps:run, app-engine:functions:run, app-engine:edge-connects:read;

// Unified analysis screens – read-only
ALLOW unified-analysis:screen-definition:read;

// SLO view – read-only
ALLOW slo:slos:read;

// Vulnerability view (Application Security) – read-only
ALLOW vulnerability-service:vulnerabilities:read;

// Optional (if you need to view extension definitions only)
ALLOW extensions:definitions:read;


u can add also Boundries to management zone.
And in maganement zone add only kubernetes, hosts, and services.
Here example of boundries:
environment:management-zone startsWith "name_of_mz";