Using resources

Overview

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

When you create or update a 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 role policies, read Member 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.

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, 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.

You can define the resources explicitly in the policy statement for a role, as in the screenshot above. Alternatively, you can define them based on a parameter that you create.

This parameter is called a role attribute. You define the role attribute when you create the role, and then you set the value of the role attribute when you assign the role to a member, either directly or through a team. For example, you can define the role attribute projectAttribute, and set the value of the role attribute to “Project A” when you assign the role to member A. Then you can set the value of the role attribute to “Project B” when you assign the role to member B. Role attributes are available for all resource types.

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:

Resource specifier syntax
resource-type/name;tag1,tag2,{property-based-selector:value}

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.

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, feature flags are scoped within a project and environment.

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

Scoped resources
resource-type/name;tag1,tag2:resource-type/name;tag3,tag4,tag5

The following example names all feature flags across all environments:

All feature flags
proj/*:env/*:flag/*

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_:

All feature flags with keys that begin with 'ops_'
proj/*:env/*:flag/ops_*

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

All feature flags in critical environments
proj/*:env/*;{critical:true}:flag/*

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.

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

Resource showing all projects
proj/*
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.

Project key is 'default'
proj/default

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

The example below names all projects with the mobile tag.

All projects tagged 'mobile'
proj/*;mobile

To learn more, read Using the advanced editor.

About resource types and scopes

To review which resources the LaunchDarkly preset roles have access to:

  1. Click the gear icon in the left sidenav to view Organization settings.
  2. Click Roles and find the role you wish to review. LaunchDarkly provides both project and organization preset roles. Select the Project or Organization tab as needed.
  3. Click the role name. A summary of the role and its policy statements appears.
  4. (Optional) Click View JSON to view the specific resources listed out by written expression.

To review which resources the LaunchDarkly base roles and preset roles have access to, expand the section below. It contains a reference list of all the supported resources in LaunchDarkly, their scopes, the 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.

Here is a reference list of all the supported resources in LaunchDarkly, their scopes, the base and preset roles that have access to the resource, and the resource identifier, ordered by written expression:

Resource typeResource scopeRoles with accessWritten expressionResource identifier
acct

acct is a unique resource specifier representing modifications to your account itself.

Billing Admin, Admin, Owner

acct

Not applicable

application

application is a top-level resource.

Admin, Architect, Writer

application/*

Application key

code-reference-repository

code-reference-repository is a top-level resource.

Project Admin, Maintainer, Developer, Writer

code-reference-repository/*

Git repository name

domain-verification

domain-verification is a top-level resource.

Admin, Owner

domain-verification/*

Domain ID

integration

integration is a top-level resource.

Admin, Architect, Writer

integration/*

Integration ID

member

member is a top-level resource.

Admin, Architect, Owner, Writer

member/*

Member ID

token

token is a child resource of members.

Admin, Architect, Member, Reader

member/*:token/*

Personal access token ID

pending-request

pending-request is a unique resource specifier representing requests to join your account.

Admin, Architect, Owner

pending-request/*

Not applicable

proj

proj is a top-level resource.

Admin, Architect, Project Admin, Maintainer, Writer

proj/*

Project key

aiconfig

aiconfig is a child of a project.

Project Admin, Maintainer, Developer, Writer

proj/*:aiconfig/*

AI Config key

ai-model-config

ai-model-config is a child of a project.

Project Admin, Maintainer, Developer, Writer

proj/*:ai-model-config/*

Model name and model ID, concatenated with a hyphen (-)

context-kind

context-kind is a child of a project.

Project Admin, Maintainer, Developer, Owner, Admin

proj/*:context-kind/*

Context kind key

env

env is a child resource of projects.

Project Admin, Maintainer, Developer, Writer

proj/*:env/*

Environment key

destination

destination is a child of both a project and an environment.

Project Admin, Maintainer, Writer

proj/*:env/*:destination/*

Data Export destination ID

experiment

experiment is a child of both a project and an environment.

Project Admin, Maintainer, Developer, Writer

proj/*:env/*:experiment/*

Experiment key

flag

flag is a child of both a project and an environment.

Project Admin, Maintainer, Developer, Contributor, Writer

proj/*:env/*:flag/*

Flag key

holdout

holdout is a child of both a project and an environment.

Project Admin, Maintainer, Developer, Writer

proj/*:env/*:holdout/*

Holdout key

segment

segment is a child of both a project and an environment.

Project Admin, Maintainer, Developer, Writer

proj/*:env/*:segment/*

Segment key

layer

layer is a child of a project.

Project Admin, Maintainer, Developer, Writer

proj/*:layer/*

Layer key

metric

metric is a child resource of projects.

Project Admin, Maintainer, Developer, Writer

proj/*:metric/*

Metric key

metric-group

metric-group is a child resource of projects.

Project Admin, Maintainer, Developer, Writer

proj/*:metric-group/*

Metric group key

release-pipeline

release-pipeline is a child resource of projects.

Project Admin, Maintainer, Owner, Admin

proj/*:release-pipeline/*

Release pipeline key

relay-proxy-config

relay-proxy-config is a top-level resource.

Admin, Architect, Owner

relay-proxy-config/*

Relay Proxy configuration ID

role

role is a top-level resource.

Admin, Architect, Owner

role/*

Role key

service-token

service-token is a top-level resource.

Admin, Architect, Reader

service-token/*

Service token ID

team

team is a top-level resource.

Admin, Architect, Owner

team/*

Team key

template

template is a top-level resource.

Admin, Architect, Writer

template/*

Workflow template key

webhook

webhook is a top-level resource.

Admin, Architect, 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 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 roles with access to these resources, read the Creating roles guide.