• HOME
  • INTEGRATIONS
  • SDKS
  • GUIDES
  • API DOCS
No results for ""
EXPAND ALL
CLOSE
launchdarkly.com

EDIT ON GITHUB

Using policies

Read time: 2 minutes
Last edited: Oct 22, 2020

Overview

This topic explains how policies work in custom roles.

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.

To learn how to create a policy, read Creating custom roles and policies.

Understanding policies

Policies are represented as JSON arrays.

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

Attribute nameDescription
effectallow or deny.
resources / notResourcesA list of resource specifiers defining the resources to which the statement applies or does not apply.
actions / notActionsA list of action specifiers defining the actions to which the statement applies or does not apply.
Inverse resource and action sets

You can only create a statement using notActions or notResources in the advanced editor.

To learn more about the advanced editor, read Writing policies in the advanced editor.

The example policy below denies access to a project, identified by it's product key. It also allows all actions on a specific flag in all projects and environments.

Here's an example policy:

1[
2 {
3 "notResources": ["proj/project-key"],
4 "actions": ["viewProject"],
5 "effect": "deny"
6 },
7 {
8 "resources": ["proj/*:env/*:flag/flag-name"],
9 "actions": ["*"],
10 "effect": "allow"
11 }
12]
Custom policies support wildcards

You can use the asterisk (*) as a wildcard character to indicate that all resources or actions should be matched.

In the example above, wildcard characters indicate that the role can perform any action on a particular flag in any project or environment.

For a more detailed explanation of the policy above, read Granting all actions to just one flag while showing only one project.

Here's an example statement:

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

If the environment ID production represents the account's Production environment, this statement denies the user from modifying any feature flags in production.

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.

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

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.
  • Any resource or action not specifically included in a policy is denied by default.

This means that statement order does not matter.

You can assign multiple custom roles to one member, and each custom role has its own policy. If you assign multiple roles to a member, be aware that if any of those custom roles allow access to a resource, then access is allowed regardless of if other roles deny that access. Adding roles to a user can only increase that user's access.

Writing policies in the advanced editor

The LaunchDarkly UI has a structured series of fields you can use to create policies.

To learn more about creating policies in LaunchDarkly, read Configuring custom roles.

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 advanced editor.
The advanced editor.

Resources are case-sensitive

When constructing your policy by hand with the advanced editor, make sure to use the resource key, which is case sensitive. If the Production environment of your default project has the key production then proj/default:env/Production will not allow actions to be taken in your default project's production environment.

Finding resource IDs

You can find resource IDs with the resource finder, which can be accessed with the “resource finder” link in either the simple or advanced editor, or using the keyboard shortcut + . (Mac) or ctl + . (Windows). All of your environments, members, feature flags, metrics, and roles will be available.

The "Find a resource ID" screen.
The "Find a resource ID" screen.