Skip to main content

Documentation Index

Fetch the complete documentation index at: https://launchdarkly-preview.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

This topic shows some examples of different roles and policies you can implement with policy statements for roles, integrations access, and Relay Proxy access. LaunchDarkly provides several preset roles which include access to common sets of features. Customers on select plans can update these presets or create their own roles. If you are looking for example roles or policies, we recommend that you start by examining the preset organization and project roles provided by LaunchDarkly. You can also add policy statements to these roles, if the permissions they provide are not quite what works best for your organization. To learn more, read Member role concepts, Organization roles, and Project roles.

​
Role examples

Use these sets of policy statements as a starting point for creating or updating roles in your account.

​
Example: View-specific permissions

One way to organize access to flags is by adding flags to a view, which is a resource to logically group flags within a project. For example, you can create “frontend” and “backend” views to organize flags within your project, and separate access to flags in those views.This policy allows access to all actions on flags in the “frontend” view in the “default” project. You can copy and modify this example to suit your needs:
      [
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/default:env/*:flag/*;view:frontend"]
        }
      ]
You can also modify this policy to specify the project and view using role attributes. This means you can reuse this role for different members working on different projects and views:
      [
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/${roleAttribute/projectKey}:env/*:flag/*;view:${roleAttribute/viewKey}"]
        }
      ]
In some cases, policies in which you specify the view using role attributes can only be created in the advanced editor. To learn more, read Use views in complex policy statements.If you use views to restrict access to sets of flags, it may be helpful to require that flags are associated with a view. One way to enforce this is to create a role that only allows the createFlag action within a particular view. For example, if you normally restrict flag creation to certain roles, you could update the policy statements for those roles to include a specific view.Here’s how:
      [
        {
          "effect": "allow",
          "actions": ["createFlag"],
          "resources": ["proj/default:env/*:flag/*;view:frontend"]
        }
      ]
When a member creates a feature flag, they can associate it with multiple views in a single request. A createFlag statement scoped to one view does not prevent a member from listing additional views in the same API call. This means that a member may be able to add a flag to a view that they do not have access to, as long as they are also adding it to a view they do have permission to add flags to. Access to the flag after it exists is still governed by your other policy statements.To learn more about views, read Views.

​
Example: Deny bypassing approvals in critical environments

This example policy uses the {property:value} pattern to deny actions on environments based on whether or not they are critical environments. You can mark any environment as critical when you create or update it. Production environments default to being marked as critical.To manage environments based on the critical property, you must specify the property-based selector as part of the modifiers for the environment resource. Limiting resources to "proj/*:env/*;{critical:true}" accomplishes this.Copy this policy and make any modifications to it to suit your needs:
      [
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*:flag/*"]
        },
        {
          "effect": "deny",
          "actions": ["bypassRequiredApproval"],
          "resources": ["proj/*:env/*;{critical:true}:flag/*"]
        }
      ]

​
Example: Grant access to flag toggles, but not flag rollout or targeting rules

This example policy allows members of the Ops team to toggle on or off any flags in the production environment. They may not change percentage rollouts or targeting rules, or manage any environments or projects.Copy this policy and make any modifications to it to suit your needs:
      [
        {
          "effect": "allow",
          "actions": ["updateOn"],
          "resources": ["proj/*:env/production:flag/*"]
        }
      ]

​
Example: Grant all actions to just one flag

The policy below allows all actions to be done to a single specified flag, flag-1.For a complete list of flag actions, read Feature flag actions.Copy this policy and make any modifications to it to suit your needs:
      [
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*:flag/flag-1"]
        }
      ]

​
Example: Grant all actions to just one flag while showing only one project

The policy below allows access only to a project a flag is in, and allows you to perform actions on that flag. In this example, both the project and the flag are specified using role attributes. When you assign this role to a member or team, you are prompted to fill in the projectKey and flagKey referenced in this role. This means you can reuse this role for different members working on different projects and flags.Copy this policy and make any modifications to it to suit your needs:
      [
        {
          "effect": "allow",
          "actions": ["viewProject"],
          "resources": ["proj/${roleAttribute/projectKey}"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/${roleAttribute/projectKey}:env/*:flag/${roleAttribute/flagKey}"]
        }
      ]

​
Example: Restrict actions within production environments

This policy allows using only these actions in the production environment:
  • updateFlagVariations
  • updateTags
This means you can take all other actions in any other non-production environment. In this example, the environment is set to the production environment, but the project is specified using a role attribute. When you assign this role to a member or team, you are prompted to fill in the projectKey referenced in this role. This means you can reuse this role for different members working on different projects.Copy this policy and make any modifications to it to suit your needs:
      [
        {
          "effect": "allow",
          "actions": ["viewProject"],
          "resources": ["proj/${roleAttribute/projectKey}"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/${roleAttribute/projectKey}:env/*:flag/*"]
        },
        {
          "effect": "deny",
          "notActions": [
            "updateFlagVariations",
            "updateTags"
            ],
          "resources": ["proj/${roleAttribute/projectKey}:env/production:flag/*"]
        }
      ]

​
Example: Allow access to flags, metrics, and segments in one project

In this example, the policy allows specific flag actions in one project, all segment actions in all projects, and all metric actions in all projects. The particular project is specified using a role attribute. When you assign this role to a member or team, you are prompted to fill in the projectKey referenced in this role.Copy this policy and make any modifications to it to suit your needs:
      [
        {
          "effect": "allow",
          "notActions": [
            "createFlag",
            "updateTargets",
            "updateRules",
            "createExperiment",
            "deleteExperiment",
            "updateScheduledChanges"
          ],
          "resources": ["proj/${roleAttribute/projectKey}:env/*:flag/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*:segment/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:metric/*"]
        }
      ]

​
Example: Deny access to the production environment

In the next example, the environment key production represents the account’s production environment in all projects. This policy denies the member from modifying any feature flags in production:
      [
        {
          "effect": "deny",
          "actions": ["*"],
          "resources": ["proj/*:env/production:flag/*"]
        }
      ]
You can also name an “inverse” set of resources by using notResources in a statement. notResources explicitly allows all actions to feature flags across all environments except an environment you specify.In the example below, the combination of notResources and the allow effect gives access to all environments except the production environment.Here’s how:
      [
        {
          "effect": "allow",
          "actions": ["*"],
          "notResources": ["proj/*:env/production:flag/*"]
        }
      ]

​
Base role templates

Unlike the LaunchDarkly-provided preset roles, you cannot edit or view policy details of the base roles in the LaunchDarkly user interface. The sections below show the policy details for these roles. You can copy and modify these Reader, Writer, Admin, and No access role templates for your own roles if needed.

​
Reader role

Copy this Reader base role and make any modifications to it to suit your needs:
      [
        {
          "effect": "allow",
          "actions": ["viewProject"],
          "resources": ["proj/*"]
        },
        {
          "effect": "allow",
          "actions": ["createAccessToken"],
          "resources": ["member/*:token/*"]
        }
      ]

​
Writer role

Because permissions are set to deny by default, you must explicitly allow actions for the Writer role. The code snippet below is a replication of LaunchDarkly’s Writer base role. You can copy it and make adjustments as needed.Copy this Writer base role and make any modifications to it to suit your needs:
      [
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["application/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["code-reference-repository/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["integration/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["member/*:token/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": [
            "proj/*:env/*:aiconfig/*"
          ]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*:destination/*"]
        },
          {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*:experiment/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*:flag/*"]
        },
        {
          "effect": "deny",
          "actions": ["bypassRequiredApproval"],
          "resources": ["proj/*:env/*:flag/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*:holdout/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*:segment/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:layer/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:metric/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:metric-group/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:view/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["relay-proxy-config/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:release-policy/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["service-token/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["template/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["webhook/*"]
        }
      ]

​
Admin Role

Because permissions are set to deny by default, you must explicitly allow actions for the Admin role. The code snippet below is a replication of LaunchDarkly’s Admin base role. You can copy it and make adjustments as needed.Copy this Admin base role and make any modifications to it to suit your needs:

      [
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["acct"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["application/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["code-reference-repository/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["domain-verification/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["integration/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["member/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["member/*:token/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["pending-request/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*:aiconfig/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:context-kind/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*:destination/*"]
        },
          {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*:experiment/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*:flag/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*:holdout/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:env/*:segment/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:layer/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:metric/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:metric-group/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:view/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:release-pipeline/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["proj/*:release-policy/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["member/*:token/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["relay-proxy-config/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["role/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["service-token/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["team/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["template/*"]
        },
        {
          "effect": "allow",
          "actions": ["*"],
          "resources": ["webhook/*"]
        }
      ]

​
No access role

Permissions are set to deny by default. In other words, by default roles cannot take any actions on any resources. You must create a policy that provides the level of access you prefer. An empty policy is equivalent to the Member preset role or the No access base role.