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 =, !=, and IN.

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 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>

  • null
  • WHERE <condition name> <condition operator> "<condition value>"

Example: WHERE settings:schemaId = "builtin:container.monitoring-rule"

  • Conditions are optional.
  • To add multiple conditions to a 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
    (Applies only to lists.)

<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.

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 the settings service (there is no condition in the first statement)
  • write objects in the settings service only where settings:schemaId is equal to builtin: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-rule
ALLOW 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:

  1. Check for unconditional DENY on a service request and reject if it matches.
  2. Check for conditional DENY on a service request that matches the request, and reject if it matches.
  3. Check for unconditional ALLOW on a service request, and grant access if it matches.
  4. Check for conditional ALLOW on a service request that matches the request, and grant access if it matches.
  5. If nothing matches, reject access.