This page uses some simple examples to give you a quick overview of how to work with IAM policy statements.
For a generated list of all supported values for each IAM service, permission, and condition, see IAM services reference.
These examples use the Dynatrace Settings service (settings
), which enables you to manage the following permissions:
schemas:read
objects:read
objects:write
It supports condition settings:schemaId
, which supports operators =
, !=
, and IN
.
In its most basic form, a policy statement starts with the ALLOW
keyword, which is followed by the service (in these examples, settings
), and then a permission (such as schemas:read
). A statement can include an optional condition. Policies can contain up to 100 statements.
ALLOW <service>
:<permission>
WHERE <condition>
;
Component
Possible values
policy
A policy
consists of one or more policy statements, with one statement
or comment
per line.
<statement>
ALLOW <service>
:<permission>
<condition>
;
<service>
settings
cloudautomation
environment:roles
<permission>
<condition>
WHERE
<condition name>
<condition operator>
"<condition value>
"Example: WHERE settings:schemaId = "builtin:container.monitoring-rule"
statement
, use AND
<condition name>
Name of <permission>
-specific or global condition
Conditions supported by permissions are described in IAM services reference.
<condition operator>
=
!=
IN
<condition value>
If <condition operator>
is =
or !=
, the <condition value>
must be a single value in quotations like this:
"<value1>
"
In this example <condition>
:
WHERE settings:schemaId = "builtin:container.monitoring-rule"
<condition name>
is settings:schemaId
<condition value>
is one possible value of settings:schemaId
If <condition operator>
is IN
, the <condition value>
must be a comma-separated list of values in parentheses like this:
("<value1>
", … , "<valueN>
")
In this example <condition>
:
WHERE settings:schemaId IN ("builtin:container.monitoring-rule", "builtin:container.built-in-monitoring-rule")
<condition name>
is settings:schemaId
<condition value>
is a list containing two possible values of settings:schemaId
<comment>
A comment explaining the policy. Everything between a double slash (//
) and the end of the line is comment text.
In this example, a user that belongs to a group to which this policy is assigned has read access to all schemas in the Dynatrace settings
service.
ALLOW settings:schemas:read;
This example modifies example 1 by adding a condition to limit read access to just one specific schema in the Dynatrace settings
service.
ALLOW settings:schemas:read WHERE settings:schemaId = "builtin:container.monitoring-rule";
The condition is added to this example statement by adding keyword WHERE
followed by the condition, which consists of three parts:
settings:schemaId
)=
)"builtin:container.monitoring-rule"
)So this statement says a user that belongs to a group to which this policy is assigned can read schemas in the settings
service, but only if the schema is equal to builtin:container.monitoring-rule
.
If you instead used the condition operator !=
, it would mean that a user that belongs to a group to which this policy is assigned can read schemas in the settings
service, but only if the schema is NOT equal to builtin:container.monitoring-rule
.
This example modifies example 2 to show how to use the IN
operator with a list of values.
ALLOW settings:schemas:read WHERE settings:schemaId IN ("builtin:container.monitoring-rule", "builtin:container.built-in-monitoring-rule");
The condition value in this case takes form of a list of schema IDs enclosed with parentheses and delimited with commas.
So this statement says a user that belongs to a group to which this policy is assigned can read schemas in the settings
service, but only if the schema ID is in this list, and then it defines a comma-separated list of two schema IDs:
("builtin:container.monitoring-rule", "builtin:container.built-in-monitoring-rule")
Each policy can have multiple statements.
Example policy with two statements:
ALLOW settings:objects:read;ALLOW settings:objects:write WHERE settings:schemaId = "builtin:container.monitoring-rule";
In this example, a user that belongs to a group to which this policy is assigned can:
objects
in the settings
service (there is no condition in the first statement)objects
in the settings
service only where settings:schemaId
is equal to builtin:container.monitoring-rule
Instead of listing permission statements on separate lines, you can combine statements into one line:
ALLOW settings:objects:read, settings:objects:write WHERE settings:schemaId = "builtin:container.monitoring-rule";
A policy with this statement grants read and write access to builtin:container.monitoring-rule
, with the WHERE condition applying to both.
To explain a policy or statements in it, you can add one or more standalone comment lines:
// Read and Write access to monitoring-ruleALLOW settings:objects:read, settings:objects:write WHERE settings:schemaId = "builtin:container.monitoring-rule";
You can also add a comment to a statement line:
ALLOW settings:objects:read; // Allows the user to read all `objects` in the `settings` service
A DENY
statement always overrules an ALLOW
statement.
For example:
DENY storage:logs:read;
If there is any DENY
statement assigned and it matches a given request, all subsequent ALLOW
statements are ignored.
Try to avoid using DENY
statements without a condition, as they would block the whole API for the users. This is not recommended, as it can create complex policy situations that are hard to resolve.
Instead of using DENY
, try to grant users only the access they need via dedicated ALLOW
statements with conditions or by leveraging policy boundaries.
For performance reasons, it is recommended to include WHERE
conditions in your DENY
permissions statements, except for storage services. Storage services don't support conditional DENY statements and will execute them as unconditional DENY.
The evaluation order for DENY
is as follows:
DENY
on a service request and reject if it matches.DENY
on a service request that matches the request, and reject if it matches.ALLOW
on a service request, and grant access if it matches.ALLOW
on a service request that matches the request, and grant access if it
matches.