No results for ""
EXPAND ALL
  • Home
  • Integrations
  • SDKs
  • Guides
  • API docs
launchdarkly.com

Example policies and templates

Read time: 9 minutes
Last edited: Oct 21, 2024

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.

Custom role examples

By default, custom roles cannot take any actions on any resources. You must create a policy that provides the level of access you prefer.

Use these custom role policy examples as a starting point for creating your own custom roles.

Example: Grant access to specific environments and flags

Expand Example: Grant access to specific environments and flags, by tag

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/*"]
  }
]
Expand Example: Grant access to specific environments and flags, by tag and property-based selector

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

[
  {
    "effect": "allow",
    "actions": ["*"],
    "resources": ["proj/*:env/*;fedramp-enabled,{critical:true}"]
  },
  {
    "effect": "allow",
    "actions": ["*"],
    "resources": ["proj/*:env/*;fedramp-enabled,{critical:true}:flag/*"]
  }
]

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

[
  {
    "effect": "allow",
    "actions": ["*"],
    "resources": ["proj/*:env/*;{critical:false}:flag/*;support"]
  }
]
Expand Example: Deny access to bypass 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 role 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: 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.

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 Tags in custom role policies.

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

Expand 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 role 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

Expand 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 role 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

Expand 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, the flag is called flag-1.

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

[
  {
    "effect": "allow",
    "actions": ["viewProject"],
    "resources": ["proj/project-1"]
  },
  {
    "effect": "allow",
    "actions": ["*"],
    "resources": ["proj/project-1:env/*:flag/flag-1"]
  }
]

Example: Restrict actions within production environments

Expand Example: Restrict actions within production environments

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

  • updateFlagVariations
  • updateTags

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

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

[
  {
    "effect": "allow",
    "actions": ["viewProject"],
    "resources": ["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 No access role.

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

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

In this example, we 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.

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

[
  {
    "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/*"]
  }
]

Example: Deny access to the production environment

Expand Example: Deny access to the production environment

In the next example, the environment key production represents the account's Production environment. This statement 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/*"]
  }
]

Custom role templates

You can copy and modify these Reader, Writer, and Admin role templates for your own custom roles.

Built-in Reader role

Expand Built-in Reader role

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

[
  {
    "effect": "allow",
    "actions": ["viewProject"],
    "resources": ["proj/*"]
  },
  {
    "effect": "allow",
    "actions": ["createAccessToken"],
    "resources": ["member/*:token/*"]
  }
]

Built-in Writer role

Expand Built-in 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 built-in Writer role. You can copy it and make adjustments as needed.

Copy this Writer 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/*"]
  },
  {
    "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/*:metric-group/*"]
  },
  {
    "effect": "allow",
    "actions": ["*"],
    "resources": ["relay-proxy-config/*"]
  },
  {
    "effect": "allow",
    "actions": ["*"],
    "resources": ["service-token/*"]
  },
  {
    "effect": "allow",
    "actions": ["*"],
    "resources": ["template/*"]
  },
  {
    "effect": "allow",
    "actions": ["*"],
    "resources": ["webhook/*"]
  }
]

Built-in Admin Role

Expand Built-in 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 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": ["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/*: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/*:release-pipeline/*"]
  },
  {
    "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

Expand No access role

Permissions are set to deny by default. In other words, by default, custom 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 built-in No access role.