No results for ""
EXPAND ALL
  • Home
  • API docs

GIVE DOCS FEEDBACK

Using resources

Read time: 6 minutes
Last edited: May 20, 2024

Overview

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

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

About the resource specifier syntax

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

The pattern to specify a resource looks like this:

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.

In the example below, we create a resource that names all of the projects in an account:

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.

In the example below, we name a project by the default key.

proj/default

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

In the example below, we name all projects with the mobile tag.

proj/*;mobile

Scoping resources

The term "scoping" refers to identifying resources in relation to other resources and the hierarchy of permissions that connects them.

Resources can be scoped within parent resources. For example, metrics are scoped within a project, and feature flags are scoped within a project and environment.

Name scoped resources by using the resource syntax structure depicted below:

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

In the following example, we name all feature flags across all environments:

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, we could name all feature flags whose keys start with ops_:

proj/*:env/*:flag/ops_*

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

proj/*:env/*;{critical:true}:flag/*

About resource types and scopes

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 typeResource scopeBuilt-in role accessWritten expressionResource 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/admin

domain-verification/*

Domain ID

experiment

experiment is a child of both a project and environments.

Writer

proj/*:env/*:experiment/*

Experiment key

integration

integration is a top-level resource.

Writer

integration/*

Integration ID

member

member is a top-level resource.

Owner/admin

member/*

Member ID

token

token is a child resource of members.

Reader

member/*:token/*

Personal access token ID

proj

proj is a top-level resource.

Writer

proj/*

Project key

context-kind

context-kind is a child of a project.

Owner/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 environments.

Writer

proj/*:env/*:destination/*

Data Export destination ID

flag

flag is a child of both a project and environments.

Writer

proj/*:env/*:flag/*

Flag key

segment

segment is a child of both a project and environments.

Writer

proj/*:env/*:segment/*

Segment 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

pending-requests

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

Owner/admin

pending-requests

Not applicable

release-pipeline

release-pipeline is a child resource of projects.

Owner/admin

proj/*:release-pipeline/*

Release pipeline key

relay-proxy-config

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

Writer

relay-proxy-config/*

Relay Proxy configuration ID

role

role is a top-level resource.

Owner/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/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

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.

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