Example policies and templates
Read time: 4 minutes
Last edited: Apr 18, 2023
Overview
This topic shows some examples of different types of policies you can implement with policy filters for custom roles, integrations access, and Relay Proxy access.
It also provides templates you can copy and modify for your own custom roles, including Reader, Writer, and Admin roles.
Use the viewProject action to allow or deny members viewing access to one or more projects. To learn more, read Creating private projects with custom roles.
Example: Granting access to specific environments and flags
Expand Example: Granting access to specific environments and flags
This example policy uses the * wildcard to allow members of the QA team to administer environments that have tags beginning with qa_, such as qa_test, qa_production, and so on. This policy also allows members to manage flags in environments that have tags beginning with qa_.
To manage flags in environments tagged qa_*, you must specify the flag-level resource you want to control. Limiting resources to "proj/*:env/*;qa_*" lets you manage the environment itself.
When you recreate this custom role, keep the By default, members can view all LaunchDarkly content box checked.
Copy this role and make any modifications to it to suit your needs:
[{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*;qa_*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*;qa_*:/flag/*"]}]
Example: tag-specific permissions
Expand Example: tag-specific permissions
One way to organize access to resources is by tagging individual resources, and then creating custom roles with access based on those tags. For example, you can create a dev tag for your environments and use it in a policy to allow access only to development environments. You can add tags to projects, environments, segments, flags, and metrics.
When you recreate this custom role, keep the By default, members can view all LaunchDarkly content box checked.
Copy this role and make any modifications to it to suit your needs:
[{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*:flag/*;dev"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*;dev"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*;dev"]}]
Anyone with this custom role can edit resources that have a dev tag.
For more tag policy examples, read Using tags in custom role policies.
Example: Granting access to flag toggles, but not flag rollout or targeting rules
Expand Example: Granting 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.
When you recreate this custom role, keep the By default, members can view all LaunchDarkly content box checked.
Policies require you to use project and environment keys, not names. If you use their names, the policies will not affect anything.
Copy this role and make any modifications to it to suit your needs:
[{"effect": "allow","actions": ["updateOn"],"resources": ["proj/*:env/production:flag/*"]}]
Example: Granting all actions to just one flag
Expand Example: Granting all actions to just one flag
The policy below allows all actions to be done to a single specified flag, flag-1. When you recreate this custom role, keep the By default, members can view all LaunchDarkly content box checked.
For a complete list of flag actions, read Feature flag actions.
Copy this role and make any modifications to it to suit your needs:
[{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*:flag/flag-1"]}]
Example: Granting all actions to just one flag while showing only one project
Expand Example: Granting all actions to just one flag while showing only one project
The policy below restricts access to a project a flag is in, while still allowing you to perform actions on that flag. In this example, the flag is called flag-1.
When you recreate this custom role, keep the By default, members can view all LaunchDarkly content box checked.
Copy this role and make any modifications to it to suit your needs:
[{"effect": "deny","actions": ["viewProject"],"notResources": ["proj/project-1"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*:flag/flag-1"]}]
In the example above, we use notResources to allow role recipients to view and modify project-1 exclusively. We do this by specifying which projects the member cannot view, with one exception.
This lets you restrict access to only one project without having to explicitly deny access to every project except that one.
Example: Restricting actions within production environments
Expand Example: Restricting actions within production environments
This policy allows using only these actions in the production-1 environment:
updateFlagVariationsupdateTags
This means they can take all other actions in any other non-production environment. When you recreate this custom role, keep the By default, members can view all LaunchDarkly content box checked.
Copy this role and make any modifications to it to suit your needs:
[{"effect": "deny","actions": ["viewProject"],"notResources": ["proj/project-1"]},{"effect": "allow","actions": ["*"],"resources": ["proj/project-1:env/*:flag/*"]},{"effect": "deny","notActions": ["updateFlagVariations","updateTags"],"resources": ["proj/project-1:env/production-1:flag/*"]}]
The second statement in the code snippet above allows all actions in all environments and to all flags in the project named project-1. You must specifically allow access, or the roles default to the Reader role.
Example: Allowing access to flags, metrics, and segments in one project
Expand Example: Allowing access to flags, metrics, and segments in one project
In this example, we deny all actions to all projects, but allow specific flag actions in one project, all segment actions in all projects, and all metric actions in all projects. When you restrict all actions this comprehensively, you must add each action for flags, segments, and metrics explicitly.
When you recreate this custom role, keep the By default, members can view all LaunchDarkly content box checked.
Copy this role and make any modifications to it to suit your needs:
[{"effect": "deny","notActions": ["viewProject"],"resources": ["proj/*"]},{"effect": "allow","notActions": ["createFlag","updateTargets","updateRules","createExperiment","deleteExperiment","updateScheduledChanges"],"resources": ["proj/project-1:env/*:flag/*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*:segment/*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:metric/*"]}]
Template: Built-in Reader role replication
Expand Template: Built-in Reader role replication
When you recreate this custom role, keep the By default, members can view all LaunchDarkly content box checked. If you uncheck this box, the role will not have read access to any resources.
Copy this Reader role and make any modifications to it to suit your needs:
[{"effect": "deny","actions": ["*"],"resources": ["proj/*:env/*"]},{"effect": "deny","actions": ["*"],"resources": ["proj/*:metric/*"]},{"effect": "deny","actions": ["*"],"resources": ["proj/*:env/*:flag/*"]},{"effect": "deny","actions": ["*"],"resources": ["proj/*:env/*:segment/*"]},{"effect": "deny","actions": ["*"],"resources": ["proj/*:env/*:destination/*"]},{"effect": "deny","actions": ["*"],"resources": ["proj/*:context-kind/*"]},{"effect": "deny","actions": ["*"],"resources": ["member/*"]},{"effect": "deny","actions": ["*"],"resources": ["member/*:token/*"]},{"effect": "deny","actions": ["*"],"resources": ["role/*"]},{"effect": "deny","actions": ["*"],"resources": ["integration/*"]},{"effect": "deny","actions": ["*"],"resources": ["webhook/*"]},{"effect": "deny","actions": ["*"],"resources": ["code-reference-repository/*"]},{"effect": "deny","actions": ["*"],"resources": ["acct"]}]
Template: Built-in Writer role replication
Expand Template: Built-in Writer role replication
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 built-in Writer role. You can copy it and make adjustments as needed.
If you compare the code snippet below to the Reader role replication, you'll find that every resource level is addressed except for member/*, member/*:token/*, role/*, and acct. By default, those resources are already set to deny, so you don't have to specifically deny them again.
Copy this Writer role and make any modifications to it to suit your needs:
[{"effect": "allow","actions": ["*"],"resources": ["proj/*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:metric/*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*:flag/*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*:segment/*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*:destination/*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:context-kind/*"]},{"effect": "allow","actions": ["*"],"resources": ["member/*:token/*"]},{"effect": "allow","actions": ["*"],"resources": ["integration/*"]},{"effect": "allow","actions": ["*"],"resources": ["webhook/*"]},{"effect": "allow","actions": ["*"],"resources": ["code-reference-repository/*"]}]
Template: Built-in Admin role replication
Expand Template: Built-in Admin role replication
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 built-in Admin role. You can copy it and make adjustments as needed.
Copy this Admin role and make any modifications to it to suit your needs:
[{"effect": "allow","actions": ["*"],"resources": ["proj/*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:metric/*"]},{"effect": "allow","actions": ["*"],"resources": ["member/*"]},{"effect": "allow","actions": ["*"],"resources": ["member/*:token/*"]},{"effect": "allow","actions": ["*"],"resources": ["role/*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*:flag/*"]},{"effect": "allow","actions": ["*"],"resources": ["integration/*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*:segment/*"]},{"effect": "allow","actions": ["*"],"resources": ["webhook/*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:context-kind/*"]},{"effect": "allow","actions": ["*"],"resources": ["code-reference-repository/*"]},{"effect": "allow","actions": ["*"],"resources": ["proj/*:env/*:destination/*"]},{"effect": "allow","actions": ["*"],"resources": ["acct"]}]
Template: No access role replication
Expand Template: No access role replication
Permissions are set to deny by default except for the viewProject and createAccessToken actions. You must explicitly deny those actions for the No access role. The code snippet below is a replication of LaunchDarkly's built-in No access role. You can copy it and make adjustments as needed.
Copy this No access role and make any modifications to it to suit your needs:
[{"effect": "deny","actions": ["viewProject"],"resources": ["proj/*"]}]