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.
-
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
.
ALLOW statement
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 |
| ALLOW |
|
|
| |
|
Example:
|
| Name of Conditions supported by permissions are described in IAM services reference. |
|
|
| If In this example
If In this example
|
| A comment explaining the policy. Everything between a double slash ( |
Example 1: simple ALLOW 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.
ALLOW 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.
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:
- 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.
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")
Example 4: statements on separate lines
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:
- 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:
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.
Example 6: statement with comments
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
DENY statement
A DENY
statement always overrules an ALLOW
statement.
For example:
DENY storage:logs:read WHERE storage:k8s.namespace.name = "PRODUCTION";
If there is any DENY
statement assigned and it matches a given request, all subsequent ALLOW
statements are ignored.
To prevent a significant performance impact, Grail does not support DENY
with record-level permissions.
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.
The evaluation order for DENY
is as follows:
- Check for unconditional
DENY
on a service request and reject if it matches. - Check for conditional
DENY
on a service request that matches the request, and reject if it matches. - Check for unconditional
ALLOW
on a service request, and grant access if it matches. - Check for conditional
ALLOW
on a service request that matches the request, and grant access if it matches. - If nothing matches, reject access.