IAM policy statement syntax and examples
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.
-
Additionally, global conditions can be used in any policy.
-
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=
,!=
, andIN
.
Syntax
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.
ALLOW <service>
:<permission>
WHERE <condition>
;
Component | Possible values |
---|---|
policy | A |
| ALLOW |
|
|
| |
|
Example:
|
| Name of Conditions supported by permissions are described in IAM services reference. |
|
|
| If In this example
If In this example
|
Example 1: simple statement
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.
1ALLOW settings:schemas:read;
Example 2: condition - single value
This example modifies example 1 by adding a condition to limit read access to just one specific schema in the Dynatrace settings
service.
1ALLOW 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:
- condition name (
settings:schemaId
) - condition operator (
=
) - condition value (
"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
.
Example 3: condition - list of values
This example modifies example 2 to show how to use the IN
operator with a list of values.
1ALLOW 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")
Example 4: statements on separate lines
Each policy can have multiple statements.
Example policy with two statements:
1ALLOW settings:objects:read;23ALLOW 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:
- read all
objects
in thesettings
service (there is no condition in the first statement) - write
objects
in thesettings
service only wheresettings:schemaId
is equal tobuiltin:container.monitoring-rule
Example 5: statements combined
Instead of listing permission statements on separate lines, you can combine statements into one line:
1ALLOW 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.