Your accountRolesManaging roles

Example roles and policies

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: Grant 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 policy and make any modifications to it to suit your needs:

QA team policy
1[
2  {
3    "effect": "allow",
4    "actions": ["*"],
5    "resources": ["proj/*:env/*;qa_*"]
6  },
7  {
8    "effect": "allow",
9    "actions": ["*"],
10    "resources": ["proj/*:env/*;qa_*:flag/*"]
11  }
12]

Here are two example policies that use the {property:value} pattern to allow 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.

In the first example, the policy allows members of the DevOps team to administer environments that are marked as critical and tagged as fedramp-enabled. This policy also allows members to manage flags in environments that are marked as critical and tagged as fedramp-enabled.

Copy this policy and make any modifications to it to suit your needs:

DevOps team policy
1[
2  {
3    "effect": "allow",
4    "actions": ["*"],
5    "resources": ["proj/*:env/*;fedramp-enabled,{critical:true}"]
6  },
7  {
8    "effect": "allow",
9    "actions": ["*"],
10    "resources": ["proj/*:env/*;fedramp-enabled,{critical:true}:flag/*"]
11  }
12]

In the second example, the policy allows members of the Support Team to perform all actions on all environments not marked as critical with flags tagged with support.

Copy this policy and make any modifications to it to suit your needs:

Support Team policy
1[
2  {
3    "effect": "allow",
4    "actions": ["*"],
5    "resources": ["proj/*:env/*;{critical:false}:flag/*;support"]
6  }
7]

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:

Deny bypassing approvals in critical environments
1[
2  {
3    "effect": "allow",
4    "actions": ["*"],
5    "resources": ["proj/*:env/*:flag/*"]
6  },
7  {
8    "effect": "deny",
9    "actions": ["bypassRequiredApproval"],
10    "resources": ["proj/*:env/*;{critical:true}:flag/*"]
11  }
12]

Example: Tag-specific permissions

One way to organize access to resources is by tagging individual resources, and then creating 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.

Copy this policy and make any modifications to it to suit your needs:

Dev-tagged resources
1[
2  {
3    "effect": "allow",
4    "actions": ["*"],
5    "resources": ["proj/*:env/*:flag/*;dev"]
6  },
7  {
8    "effect": "allow",
9    "actions": ["*"],
10    "resources": ["proj/*:env/*;dev"]
11  },
12  {
13    "effect": "allow",
14    "actions": ["*"],
15    "resources": ["proj/*;dev"]
16  }
17]

Anyone with this role can edit resources that have a dev tag.

For more tag policy examples, read Tags in role policies.

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:

Ops team
1[
2  {
3    "effect": "allow",
4    "actions": ["updateOn"],
5    "resources": ["proj/*:env/production:flag/*"]
6  }
7]

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:

One flag
1[
2  {
3    "effect": "allow",
4    "actions": ["*"],
5    "resources": ["proj/*:env/*:flag/flag-1"]
6  }
7]

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:

One flag
1[
2  {
3    "effect": "allow",
4    "actions": ["viewProject"],
5    "resources": ["proj/${roleAttribute/projectKey}"]
6  },
7  {
8    "effect": "allow",
9    "actions": ["*"],
10    "resources": ["proj/${roleAttribute/projectKey}:env/*:flag/${roleAttribute/flagKey}"]
11  }
12]

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:

Non-prod environments
1[
2  {
3    "effect": "allow",
4    "actions": ["viewProject"],
5    "resources": ["proj/${roleAttribute/projectKey}"]
6  },
7  {
8    "effect": "allow",
9    "actions": ["*"],
10    "resources": ["proj/${roleAttribute/projectKey}:env/*:flag/*"]
11  },
12  {
13    "effect": "deny",
14    "notActions": [
15      "updateFlagVariations",
16      "updateTags"
17      ],
18    "resources": ["proj/${roleAttribute/projectKey}:env/production:flag/*"]
19  }
20]

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:

Flags, metrics, and segments
1[
2  {
3    "effect": "allow",
4    "notActions": [
5      "createFlag",
6      "updateTargets",
7      "updateRules",
8      "createExperiment",
9      "deleteExperiment",
10      "updateScheduledChanges"
11    ],
12    "resources": ["proj/${roleAttribute/projectKey}:env/*:flag/*"]
13  },
14  {
15    "effect": "allow",
16    "actions": ["*"],
17    "resources": ["proj/*:env/*:segment/*"]
18  },
19  {
20    "effect": "allow",
21    "actions": ["*"],
22    "resources": ["proj/*:metric/*"]
23  }
24]

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:

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

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:

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

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:

Reader role
1[
2  {
3    "effect": "allow",
4    "actions": ["viewProject"],
5    "resources": ["proj/*"]
6  },
7  {
8    "effect": "allow",
9    "actions": ["createAccessToken"],
10    "resources": ["member/*:token/*"]
11  }
12]

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:

Writer role
1[
2  {
3    "effect": "allow",
4    "actions": ["*"],
5    "resources": ["application/*"]
6  },
7  {
8    "effect": "allow",
9    "actions": ["*"],
10    "resources": ["code-reference-repository/*"]
11  },
12  {
13    "effect": "allow",
14    "actions": ["*"],
15    "resources": ["integration/*"]
16  },
17  {
18    "effect": "allow",
19    "actions": ["*"],
20    "resources": ["member/*:token/*"]
21  },
22  {
23    "effect": "allow",
24    "actions": ["*"],
25    "resources": ["proj/*"]
26  },
27  {
28    "effect": "allow",
29    "actions": ["*"],
30    "resources": ["proj/*:aiconfig/*"]
31  },
32  {
33    "effect": "allow",
34    "actions": ["*"],
35    "resources": ["proj/*:env/*"]
36  },
37  {
38    "effect": "allow",
39    "actions": ["*"],
40    "resources": ["proj/*:env/*:destination/*"]
41  },
42    {
43    "effect": "allow",
44    "actions": ["*"],
45    "resources": ["proj/*:env/*:experiment/*"]
46  },
47  {
48    "effect": "allow",
49    "actions": ["*"],
50    "resources": ["proj/*:env/*:flag/*"]
51  },
52  {
53    "effect": "deny",
54    "actions": ["bypassRequiredApproval"],
55    "resources": ["proj/*:env/*:flag/*"]
56  },
57  {
58    "effect": "allow",
59    "actions": ["*"],
60    "resources": ["proj/*:env/*:holdout/*"]
61  },
62  {
63    "effect": "allow",
64    "actions": ["*"],
65    "resources": ["proj/*:env/*:segment/*"]
66  },
67  {
68    "effect": "allow",
69    "actions": ["*"],
70    "resources": ["proj/*:layer/*"]
71  },
72  {
73    "effect": "allow",
74    "actions": ["*"],
75    "resources": ["proj/*:metric/*"]
76  },
77  {
78    "effect": "allow",
79    "actions": ["*"],
80    "resources": ["proj/*:metric-group/*"]
81  },
82  {
83    "effect": "allow",
84    "actions": ["*"],
85    "resources": ["proj/*:metric-group/*"]
86  },
87  {
88    "effect": "allow",
89    "actions": ["*"],
90    "resources": ["relay-proxy-config/*"]
91  },
92  {
93    "effect": "allow",
94    "actions": ["*"],
95    "resources": ["service-token/*"]
96  },
97  {
98    "effect": "allow",
99    "actions": ["*"],
100    "resources": ["template/*"]
101  },
102  {
103    "effect": "allow",
104    "actions": ["*"],
105    "resources": ["webhook/*"]
106  }
107]

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:

Admin role
1[
2  {
3    "effect": "allow",
4    "actions": ["*"],
5    "resources": ["acct"]
6  },
7  {
8    "effect": "allow",
9    "actions": ["*"],
10    "resources": ["application/*"]
11  },
12  {
13    "effect": "allow",
14    "actions": ["*"],
15    "resources": ["code-reference-repository/*"]
16  },
17  {
18    "effect": "allow",
19    "actions": ["*"],
20    "resources": ["domain-verification/*"]
21  },
22  {
23    "effect": "allow",
24    "actions": ["*"],
25    "resources": ["integration/*"]
26  },
27  {
28    "effect": "allow",
29    "actions": ["*"],
30    "resources": ["member/*"]
31  },
32  {
33    "effect": "allow",
34    "actions": ["*"],
35    "resources": ["member/*:token/*"]
36  },
37  {
38    "effect": "allow",
39    "actions": ["*"],
40    "resources": ["pending-request/*"]
41  },
42  {
43    "effect": "allow",
44    "actions": ["*"],
45    "resources": ["proj/*"]
46  },
47  {
48    "effect": "allow",
49    "actions": ["*"],
50    "resources": ["proj/*:aiconfig/*"]
51  },
52  {
53    "effect": "allow",
54    "actions": ["*"],
55    "resources": ["proj/*:context-kind/*"]
56  },
57  {
58    "effect": "allow",
59    "actions": ["*"],
60    "resources": ["proj/*:env/*"]
61  },
62  {
63    "effect": "allow",
64    "actions": ["*"],
65    "resources": ["proj/*:env/*:destination/*"]
66  },
67    {
68    "effect": "allow",
69    "actions": ["*"],
70    "resources": ["proj/*:env/*:experiment/*"]
71  },
72  {
73    "effect": "allow",
74    "actions": ["*"],
75    "resources": ["proj/*:env/*:flag/*"]
76  },
77  {
78    "effect": "allow",
79    "actions": ["*"],
80    "resources": ["proj/*:env/*:holdout/*"]
81  },
82  {
83    "effect": "allow",
84    "actions": ["*"],
85    "resources": ["proj/*:env/*:segment/*"]
86  },
87  {
88    "effect": "allow",
89    "actions": ["*"],
90    "resources": ["proj/*:layer/*"]
91  },
92  {
93    "effect": "allow",
94    "actions": ["*"],
95    "resources": ["proj/*:metric/*"]
96  },
97  {
98    "effect": "allow",
99    "actions": ["*"],
100    "resources": ["proj/*:metric-group/*"]
101  },
102  {
103    "effect": "allow",
104    "actions": ["*"],
105    "resources": ["proj/*:release-pipeline/*"]
106  },
107  {
108    "effect": "allow",
109    "actions": ["*"],
110    "resources": ["member/*:token/*"]
111  },
112  {
113    "effect": "allow",
114    "actions": ["*"],
115    "resources": ["relay-proxy-config/*"]
116  },
117  {
118    "effect": "allow",
119    "actions": ["*"],
120    "resources": ["role/*"]
121  },
122  {
123    "effect": "allow",
124    "actions": ["*"],
125    "resources": ["service-token/*"]
126  },
127  {
128    "effect": "allow",
129    "actions": ["*"],
130    "resources": ["team/*"]
131  },
132  {
133    "effect": "allow",
134    "actions": ["*"],
135    "resources": ["template/*"]
136  },
137  {
138    "effect": "allow",
139    "actions": ["*"],
140    "resources": ["webhook/*"]
141  }
142]

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.