Using resources

Read time: 8 minutes

Last edited: Jan 08, 2025

Overview

This topic explains how to specify different resources to use with custom roles, integrations access, and Relay Proxy access.

When you create a custom role, you specify resources that the role can or cannot access. Then, you grant access to a specific set of actions associated with that resource.

To learn more about how resources are structured within custom role policies, read Custom role concepts.

Specifying resources in the policy builder

When you create a policy statement using the policy builder, you use the Scope menu to specify the resources that the policy affects:

The "Scope" and "Select [resources]" menus when defining a policy scoped to a select set of applications.

Some resources are "scoped" within specific parent resources. In other words, some resources require you to specify other resources in order to be correctly identified. For example, metrics are scoped within a given project, and feature flags are scoped within a project and environment. In the policy builder, if you initially select the "flag" resource type, the policy builder prompts you to specify projects and environments before you can continue.

Specifying resources in the advanced editor

When you create a policy statement using the advanced editor, you specify resources in JSON. LaunchDarkly uses a resource specifier syntax to name resources or collections of resources. This is a precise, flexible taxonomy that lets you identify and control any resource in your LaunchDarkly account.

The syntax to specify a resource looks like this:

The example above shows two tags separated by a comma. Tags are optional. It also shows a property-based selector. If you don't need to use any tags or selectors, you can omit the semicolon (;) and all content following.

You can name scoped resources by using the resource syntax structure depicted below:

The following example names all feature flags across all environments:

In the example above, proj/*:includes all named projects in the list of results. env/*: includes all environments in the list of results. flag/*: includes all flags in the list of results. This example will return very broad results because of how comprehensive its permissions are.

Resource types do not share permissions

Member permissions are specific to each resource type, and different types do not share or inherit permissions. For example, if you set member permissions for a project with the ID default using proj/default, the member does not have the same permissions for the project's environments unless you also set member permissions for proj/default:env/*.

For a more refined example, you could name all feature flags whose keys start with ops_:

Finally, you could name all feature flags in critical environments:

Additional examples of resource specifier syntax

Expand the section below to review additional examples of resource specifier syntax. You only need this information if you are creating your policy statements in JSON. You do not need to review this information if you use the policy builder.

Expand additional examples of resource specifier syntax

The example below creates a resource that names all of the projects in an account:

Syntax supports wildcards

The resource syntax accepts globs and wildcards, so you can name collections of resources with *. You can also name a specific project by its key.

The example below names a project by the default key.

You can name sets of resources down to the tag level.

The example below names all projects with the mobile tag.

To learn more, read Using the advanced editor.

About resource types and scopes

Expand the section below to review a reference list of all the supported resources in LaunchDarkly, their scopes, the built-in role that has access to the resource, and the resource identifier, ordered by written expression.

You only need this information if you are creating your policy statements in JSON. You do not need to review this information if you use the policy builder. In the policy builder all of the supported resources are available directly in the user interface.

Expand reference list of supported resources in LaunchDarkly

Here is a reference list of all the supported resources in LaunchDarkly, their scopes, the built-in role that has access to the resource, and the resource identifier, ordered by written expression:

Resource type	Resource scope	Built-in role access	Written expression	Resource identifier
`acct`	`acct` is a unique resource specifier representing modifications to your account itself.	Owner	`acct`	Not applicable
`application`	`application` is a top-level resource.	Writer	`application/*`	Application key
`code-reference-repository`	`code-reference-repository` is a top-level resource.	Writer	`code-reference-repository/*`	Git repository name
`domain-verification`	`domain-verification` is a top-level resource.	Owner or Admin	`domain-verification/*`	Domain ID
`integration`	`integration` is a top-level resource.	Writer	`integration/*`	Integration ID
`member`	`member` is a top-level resource.	Owner or Admin	`member/*`	Member ID
`token`	`token` is a child resource of `members`.	Reader	`member/:token/`	Personal access token ID
`pending-request`	`pending-request` is a unique resource specifier representing requests to join your account.	Owner or Admin	`pending-request/*`	Not applicable
`proj`	`proj` is a top-level resource.	Writer	`proj/*`	Project key
`aiconfig`	`aiconfig` is a child of a project.	Writer	`proj/:aiconfig/`	AI config key
`context-kind`	`context-kind` is a child of a project.	Owner or Admin	`proj/:context-kind/`	Context kind key
`env`	`env` is a child resource of `projects`.	Writer	`proj/:env/`	Environment key
`destination`	`destination` is a child of both a project and an environment.	Writer	`proj/:env/:destination/*`	Data Export destination ID
`experiment`	`experiment` is a child of both a project and an environment.	Writer	`proj/:env/:experiment/*`	Experiment key
`flag`	`flag` is a child of both a project and an environment.	Writer	`proj/:env/:flag/*`	Flag key
`holdout`	`holdout` is a child of both a project and an environment.	Writer	`proj/:env/:holdout/*`	Holdout key
`segment`	`segment` is a child of both a project and an environment.	Writer	`proj/:env/:segment/*`	Segment key
`layer`	`layer` is a child of a project.	Writer	`proj/:layer/`	Layer key
`metric`	`metric` is a child resource of `projects`.	Writer	`proj/:metric/`	Metric key
`metric-group`	`metric-group` is a child resource of `projects`.	Writer	`proj/:metric-group/`	Metric group key
`release-pipeline`	`release-pipeline` is a child resource of `projects`.	Owner or Admin	`proj/:release-pipeline/`	Release pipeline key
`relay-proxy-config`	`relay-proxy-config` is a top-level resource.	Owner / Admin	`relay-proxy-config/*`	Relay Proxy configuration ID
`role`	`role` is a top-level resource.	Owner or Admin	`role/*`	Role key
`service-token`	`service-token` is a top-level resource.	Reader	`service-token/*`	Service token ID
`team`	`team` is a top-level resource.	Owner or Admin	`team/*`	Team key
`template`	`template` is a top-level resource.	Writer	`template/*`	Workflow template key
`webhook`	`webhook` is a top-level resource.	Writer	`webhook/*`	Webhook ID

The user resource is only relevant when working with older SDKs

If you are working with older SDKs, which do not yet support custom contexts, you can also reference the user resource. The user resource is scoped to a project and environment. It has one action, deleteUser. This action allows you to delete context instances, including users, which appear as context instances on the Contexts list. To learn more, read Remove a context instance.

If you are working with SDKs that have been updated for contexts, the equivalent action is deleteContextInstance, which is scoped to the environment resource. To learn more, read Environment actions.

We strongly encourage you to upgrade your SDKs to versions supporting contexts.

For a list of all actions available to each resource, read Using actions. To learn more about how to create custom roles with access to these resources, read Creating custom roles.