Using policies

Overview

This topic explains how to write policies for custom roles, integrations access, and Rely Proxy access.

Policies combine resources and actions into a set of statements that define what users can or cannot do in LaunchDarkly. To learn more, read Custom role concepts.

Understanding policies

Policies are represented as JSON arrays.

Each element in the array is a statement represented as a JSON object with three attributes:

Resource specifiers

Resource specifiers allow you to define which resources to allow or deny access to. Three commonly-used resources in custom role policies are projects, environments, and flags.

Here is how to express these resources in code:

• proj/KEY
• proj/*:env/KEY
• proj/*:env/*:flag/KEY

For a full list of available resources, read Using actions.

In these expressions KEY is the key of the project, environment, or flag. You can use the asterisk * as a wildcard character to indicate that all resources of that type should be matched. For example, proj/* indicates all projects within your account.

The colon : within a policy indicates that the resource after the : resides within the resource before the :. For example, proj/account-management:env/production refers to the production environment within the account-management project only. To learn more, read Understanding the resource specifier syntax.

Writing policies in the advanced editor

The LaunchDarkly UI has a structured series of fields you can use to create policies. If you want to write a policy by hand, however, you can use the advanced editor.

To access the advanced editor:

1. Navigate to Account Settings.
2. Click into the Roles tab.
3. Click New Role. The "Create a role" screen appears.
4. Click Advanced editor. The advanced editor opens:

The following example policy denies access to the account-management project. It also allows all actions on the checkout-flow flag in all projects and environments.

Here's the example policy:

1[
2  {
3    "notResources": ["proj/account-management"],
4    "actions": ["viewProject"],
5    "effect": "deny"
6  },
7  {
8    "resources": ["proj/*:env/*:flag/checkout-flow"],
9    "actions": ["*"],
10    "effect": "allow"
11  }
12]
COPY

In the next example, the environment key production represents the account's Production environment. This statement denies the user from modifying any feature flags in production:

1{
2    "effect": "deny",
3    "resources": ["proj/*:env/production:flag/*"],
4    "actions": ["*"]
5  }
COPY

You can also name an "inverse" set of resources by using notResources in a statement. This statement explicitly allows all actions to feature flags across all environments except the production environment.

Here's how:

1{
2    "effect": "allow",
3    "notResources": ["proj/*:env/production:flag/*"],
4    "actions": ["*"]
5  }
COPY

For more advanced policy examples, read Example policies and templates.

Policy algorithm

The algorithm for determining whether access is allowed or denied by a policy is as follows:

• If any statement in the policy explicitly denies access to a resource and action, access is denied.
• If a statement in the policy explicitly allows access to a resource and action, and no statement denies access, access is allowed
• If two policies have conflicting permission levels, the more permissive level of access is applied
• Any resource or action not specifically included in a policy is denied by default, except the viewProject action and the createAccessToken action

Statement order does not matter. You can assign multiple custom roles to one member, and each custom role has its own policy.

Permissions are cumulative. If you assign multiple custom roles to a member, and one of those custom roles allow access to a resource, then access is allowed even if other roles deny that access. Adding roles to a user can only increase that user's access.