Using policies
Read time: 3 minutes
Last edited: Oct 21, 2024
Overview
This topic explains how to work with policies for custom roles, integrations access, and Relay Proxy access.
Policies combine resources and actions into a set of statements that define what members can or cannot do in LaunchDarkly. To learn more, read Custom role concepts.
To create a new custom role, read Creating custom roles and policies.
About the policy algorithm
The algorithm for determining whether a policy allows or denies access is as follows:
- If a statement within a policy explicitly denies access to a resource and action, access is denied. This statement overrides any other statement in the policy that allows access to the resource and action.
- If a statement within a policy explicitly allows access to a resource and action, and no statement denies access, access is allowed.
- If two different policies have conflicting permission levels, the more permissive level of access is applied.
- Any resource or action not specifically included within a policy is denied by default.
Statement order does not matter.
Account members with a Reader role can only create tokens with a Reader role, whereas account members with an Owner or Admin role can create tokens with any permission level. Account members with a custom role can create access tokens that are limited to their existing permissions.
To learn more, read Minimum required actions for a role.
You can assign multiple custom roles to one member, and each custom role has its own set of policy statements.
Permissions are cumulative across roles. If you assign multiple custom roles to a member, and one of those custom roles allows access to a resource, then access is allowed even if other roles deny that access. Adding roles to a member can only increase that member's access.
About policies
Policies combine resources and actions into a set of statements that define what members can or cannot do in LaunchDarkly.
You use LaunchDarkly's Policy builder to build custom roles by selecting combinations of resources and actions the role is allowed to or forbidden from taking on them.
You can create most roles using the graphical Policy builder. If needed, you can also define a role directly in JSON, using the advanced editor.
Each element in the array is a statement represented as a JSON object with three attributes:
| Attribute name | Description |
|---|---|
effect | allow or deny. |
actions / notActions | A list of action specifiers defining the actions to which the statement applies or does not apply. |
resources / notResources | A list of resource specifiers defining the resources to which the statement applies or does not apply. |
You can only create a statement using notActions or notResources in the advanced editor. To learn more about the advanced editor, read Using the advanced editor.
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/KEYproj/*:env/KEYproj/*:env/*:flag/KEY
For a full list of available resources, read Using resources.
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 About the resource specifier syntax.
Resource specifiers can also include modifiers, such as tags and property-based selectors. To learn more, read Custom role concepts.
You can create detailed and complex policies with the advanced editor. To learn more, read Using the advanced editor.