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

EDIT ON GITHUB

Example policies and templates

Read time: 2 minutes
Last edited: Apr 07, 2021

Overview

This topic shows some examples of different types of policies you can implement with custom roles and policy filters.

It also provides two templates you can copy and modify for your own custom roles. One template is for a reader role, and one is for a writer role.

Creating private projects with custom roles

Use the viewProject action to allow or deny viewing and editing access to projects. To learn more, read Configuring private projects with custom roles.

Example: Granting access to specific environments and flags

This example policy allows members of the QA team to administer environments that are tagged qa_*, and also to manage flags in environments tagged 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.

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

Example: Granting access to kill switch features, 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.

Do not use display names for projects and environments in policies

Policies require you to use project and environment keys, not names. If you use their names, the policies will not affect anything.

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

Example: Granting 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 the Feature flag actions list.

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

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.

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

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 user 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

This policy allows using only these actions in the production-1 environment:

  • updateFlagVariations
  • updateTags

This means they can take all other actions in any other non-production environment.

1[
2 {
3 "notResources": ["proj/project-1"],
4 "actions": ["viewProject"],
5 "effect": "deny"
6 },
7 {
8 "resources": ["proj/project-1:env/*:flag/*"],
9 "actions": ["*"],
10 "effect": "allow"
11 },
12 {
13 "resources": ["proj/project-1:env/production-1:flag/*"],
14 "notActions": ["updateFlagVariations", "updateTags"],
15 "effect": "deny"
16 }
17]

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

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.

1[
2 {
3 "resources": ["proj/*"],
4 "actions": ["*"],
5 "effect": "deny"
6 },
7 {
8 "resources": ["proj/project-1:env/*:flag/*"],
9 "notActions": ["createFlag", "updateTargets", "updateRules", "createExperiment", "deleteExperiment", "updateScheduledChanges"],
10 "effect": "allow"
11 },
12 {
13 "resources": ["proj/*:env/*:segment/*"],
14 "actions": ["*"],
15 "effect": "allow"
16 },
17 {
18 "resources": ["proj/*:env/*:metric/*"],
19 "actions": ["*"],
20 "effect": "allow"
21 },
22]

Template: Built-in reader role replication

Copy this reader role and make any modifications to it to suit your needs.

1[
2 {
3 "resources": ["proj/*"],
4 "actions": ["*"],
5 "effect": "deny"
6 },
7 {
8 "resources": ["proj/*:env/*"],
9 "actions": ["*"],
10 "effect": "deny"
11 },
12 {
13 "resources": ["proj/*:metric/*"],
14 "actions": ["*"],
15 "effect": "deny"
16 },
17 {
18 "resources": ["proj/*:env/*:flag/*"],
19 "actions": ["*"],
20 "effect": "deny"
21 },
22 {
23 "resources": ["proj/*:env/*:segment/*"],
24 "actions": ["*"],
25 "effect": "deny"
26 },
27 {
28 "resources": ["proj/*:env/*:destination/*"],
29 "actions": ["*"],
30 "effect": "deny"
31 },
32 {
33 "resources": ["proj/*:env/*:user/*"],
34 "actions": ["*"],
35 "effect": "deny"
36 },
37 {
38 "resources": ["member/*"],
39 "actions": ["*"],
40 "effect": "deny"
41 },
42 {
43 "resources": ["member/*:token/*"],
44 "actions": ["*"],
45 "effect": "deny"
46 },
47 {
48 "resources": ["role/*"],
49 "actions": ["*"],
50 "effect": "deny"
51 },
52 {
53 "resources": ["integration/*"],
54 "actions": ["*"],
55 "effect": "deny"
56 },
57 {
58 "resources": ["webhook/*"],
59 "actions": ["*"],
60 "effect": "deny"
61 },
62 {
63 "resources": ["code-reference-repository/*"],
64 "actions": ["*"],
65 "effect": "deny"
66 },
67 {
68 "resources": ["acct"],
69 "actions": ["*"],
70 "effect": "deny"
71 }
72]

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.

1[
2 {
3 "resources": ["proj/*"],
4 "actions": ["*"],
5 "effect": "allow"
6 },
7 {
8 "resources": ["proj/*:env/*"],
9 "actions": ["*"],
10 "effect": "allow"
11 },
12 {
13 "resources": ["proj/*:metric/*"],
14 "actions": ["*"],
15 "effect": "allow"
16 },
17 {
18 "resources": ["proj/*:env/*:flag/*"],
19 "actions": ["*"],
20 "effect": "allow"
21 },
22 {
23 "resources": ["proj/*:env/*:segment/*"],
24 "actions": ["*"],
25 "effect": "allow"
26 },
27 {
28 "resources": ["proj/*:env/*:destination/*"],
29 "actions": ["*"],
30 "effect": "allow"
31 },
32 {
33 "resources": ["proj/*:env/*:user/*"],
34 "actions": ["*"],
35 "effect": "allow"
36 },
37 {
38 "resources": ["member/*:token/*"],
39 "actions": ["*"],
40 "effect": "allow"
41 },
42 {
43 "resources": ["integration/*"],
44 "actions": ["*"],
45 "effect": "allow"
46 },
47 {
48 "resources": ["webhook/*"],
49 "actions": ["*"],
50 "effect": "allow"
51 },
52 {
53 "resources": ["code-reference-repository/*"],
54 "actions": ["*"],
55 "effect": "allow"
56 }
57]