Policy templating

Parameterized policies can be managed only via REST API.

The policy framework allows you to create reusable policies with parameterized values restricting access to a subset of a service’s resource defined as a reference to the binding parameter.

This way, you can create a single policy with a parameter reference:

ALLOW storage:logs:read WHERE storage:dt.security_context = "${bindParam:my-policy-param}";

instead of multiple policies with explicitly defined values:

ALLOW storage:logs:read WHERE storage:dt.security_context = "context1"
ALLOW storage:logs:read WHERE storage:dt.security_context = "context2"
ALLOW storage:logs:read WHERE storage:dt.security_context = "context3"
ALLOW storage:logs:read WHERE storage:dt.security_context = "context4"
ALLOW storage:logs:read WHERE storage:dt.security_context = "context5"

Parameterized policies reduce the management effort and allow you to have single policies that act as an angle point for multiple groups. You can use parameterized policies for the segmentation of data and to offload recurring patterns. A bound policy that includes parameters can still be changed as long as the number and names of parameters don't change.

Policy parameter syntax

Parameters can be used in a policy similarly to how regular condition values are used. In the following example, a policy includes a reference to a parameter named my-policy-param.

ALLOW storage:buckets:read WHERE storage:dt.security_context = "${bindParam:my-policy-param}";

Policy parameters should be prefixed with bindParam: and enclosed in ${...}. When a user's permissions are evaluated, references are replaced with values defined while assigning the policy to a group.

IN ("${bindParam:oauthScopes}")

Configuring parameter values

Parameter values are assigned to a policy during the binding of the policy to a user group.

All parameters that are referenced in the policy need to be provided during binding time to attach the policy successfully. Otherwise, the policy would be missing necessary context information to make it effective. The values of the parameters are supplied in the body of the HTTP request. For details, see the example below.

Parameter validation

If there is a mismatch between the parameters used in the policy and the values provided while binding the policy to a group, the REST API operation returns a 400 error code response that contains information about the set of expected and supplied parameters.

Example

In this example, we have two groups, ADMINS and USERS, and we want members of those groups to have access to dedicated buckets based on the security context field.

First, we need to create a parameterized policy. Parameterized policies can be created both via API and the web UI editor. We’ll use the example from the previous section and name it BUCKETS_SECURITY_POLICY:

ALLOW storage:buckets:read WHERE storage:bucket-name = "${bindParam:bucket-name-param}";

Then we need to bind BUCKETS_SECURITY_POLICY to ADMINS and USERS groups and provide values for my-policy-param parameter. To do this, you need to use the Bindings API in the Dynatrace Account Management API in two steps. Currently, group management does not support binding policies with parameters.

Effectively, this setup translates to two policies:

Parameter validation

Binding parameterized policy to group

A policy with binding parameter references requires all necessary values to be supplied during group assignment.

As mentioned earlier, if there is a mismatch between the parameters used in the policy and the values provided while binding the policy to a group, the REST API operation returns a 400 error code response that contains information about the set of expected and supplied parameters.

Parameterized policy update

Parameterization of a policy imposes some constraints for updating the contents of the already bound policies. Modification of bound policies is allowed only if the parameter set doesn’t change; otherwise, inconsistencies with existing parameterized bindings might be introduced.

Suppose we want to add a new statement to the policy we created and bound in the previous section:

This update operation would fail because the existing bindings don’t contain all the necessary parameters to properly evaluate the policy.

An example of a valid update would look like this:

In this case, the set of parameters used in the policy stays the same, so previously created bindings can be effectively used to evaluate the updated policy.

List of values as binding parameters

In this example, the policy binds parameter storage:dt.security_context to a referenced list of values:

ALLOW storage:buckets:read WHERE storage:dt.security_context IN ("${bindParam:my-policy-param}");

A list of values can be assigned to a parameter while binding the policy to a group by providing a comma-separated list within a single string value.

Assign BUCKETS_SECURITY_POLICY to USERS with my-policy-param set to low,medium,high.

curl -X 'POST' \
'https://api.dynatrace.com/iam/v1/repo/account/ACCOUNT/bindings/BUCKETS_SECURITY_POLICY/USERS' \
-H 'accept: */*' -H 'Content-Type: application/json' \
-d '{"parameters": {"my-policy-param": "low,medium,high"}}'