Using resources

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

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:

Some resources are “scoped” within specific parent resources and require additional context 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, which means the resource must have both tag1 AND tag2. Tags are optional.

The example also shows a property-based selector, which is a way to select resources whose properties match a particular value. To learn more, read Property-based selectors.

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 and require additional context 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.

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.

Expand additional examples of resource specifier syntax

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

Resource showing all projects

      proj/*

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.

Expand reference list of supported resources in LaunchDarkly

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 type

| Resource scope

| Suggested roles

Resource identifier

| ---

| ---

| --- | | acct

| A unique resource specifier representing modifications to your account itself.

| Billing Admin, Admin, Owner

| Not applicable | | application

| A top-level resource, written as:
application/*

| Admin, Architect, Writer

| Application key | | code-reference-repository

| A top-level resource, written as:
code-reference-repository/*

| Project Admin, Maintainer, Developer, Writer

| Git repository name | | domain-verification

| A top-level resource, written as:
domain-verification/*

| Admin, Owner

| Domain ID | | integration

| A top-level resource, written as:
integration/*

| Admin, Architect, Writer

| Integration ID | | member

| A top-level resource, written as:
member/*

| Admin, Architect, Owner, Writer

| Member ID | | token

| A child of a member, written as:
member/*:token/*

| Admin, Architect, Member, Reader

| Personal access token ID | | pending-request

| A top-level resource, written as:
pending-request/*

| Admin, Architect, Owner

| Not applicable | | proj

| A top-level resource, written as:
proj/*

| Admin, Architect, Project Admin, Maintainer, Writer

| Project key | | ai-evaluation

| A child of a project, written as:
proj/*:ai-evaluation/*

| Project Admin, Maintainer, Developer, Writer

| AI evaluation key | | ai-tool

| A child of a project, written as:
proj/*:ai-tool/*

| Project Admin, Maintainer, Developer, Writer

| AI tool key | | alert

| A child of a project, written as:
proj/*:alert/*

| Project Admin, Maintainer, Owner, Admin

| Not applicable | | context-kind

| A child of a project, written as:
proj/*:context-kind/*

| Project Admin, Maintainer, Developer, Owner, Admin

| Context kind key | | env

| A child of a project, written as:
proj/*:env/*

| Project Admin, Maintainer, Developer, Writer

| Environment key | | error

| A child of a project, written as:
proj/*:error/*

| Project Admin, Maintainer, Owner, Admin

| Not applicable | | log

| A child of a project, written as:
proj/*:log/*

| Project Admin, Maintainer, Owner, Admin

| Not applicable | | observability-dashboard

| A child of a project, written as:
proj/*:observability-dashboard/*

| Project Admin, Maintainer, Owner, Admin

| Dashboard ID | | session

| A child of a project, written as:
proj/*:session/*

| Project Admin, Maintainer, Owner, Admin

| Not applicable | | trace

| A child of a project and an environment, written as:
proj/*:env/*:trace/*

| Project Admin, Maintainer, Owner, Admin

| Not applicable | | vega

| A child of a project and an environment, written as:
proj/*:env/*:vega/*

| Project Admin, Maintainer, Owner, Admin

| Conversation ID | | aiconfig

| A child of a project and an environment, written as:
proj/*:env/*:aiconfig/*

| Project Admin, Maintainer, Developer, Writer

| AI Config key | | ai-model-config

| A child of a project and an environment, written as:
proj/*:env/*:ai-model-config/*

| Project Admin, Maintainer, Developer, Writer

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

| A child of a project and an environment, written as:
proj/*:env/*:destination/*

| Project Admin, Maintainer, Writer

| Data Export destination ID | | experiment

| A child of a project and an environment, written as:
proj/*:env/*:experiment/*

| Project Admin, Maintainer, Developer, Writer

| Experiment key | | flag

| A child of a project and an environment, written as:
proj/*:env/*:flag/*

| Project Admin, Maintainer, Developer, Contributor, Writer

| Flag key | | holdout

| A child of a project and an environment, written as:
proj/*:env/*:holdout/*

| Project Admin, Maintainer, Developer, Writer

| Holdout key | | metric-data-source

| A child of a project and an environment, written as:
proj/*:env/*:metric-data-source/*

| Project Admin, Owner, Developer

| Data source key | | segment

| A child of a project and an environment, written as:
proj/*:env/*:segment/*

| Project Admin, Maintainer, Developer, Writer

| Segment key | | layer

| A child of a project, written as:
proj/*:layer/*

| Project Admin, Maintainer, Developer, Writer

| Layer key | | metric

| A child of a project, written as:
proj/*:metric/*

| Project Admin, Maintainer, Developer, Writer

| Metric key | | metric-group

| A child of a project, written as:
proj/*:metric-group/*

| Project Admin, Maintainer, Developer, Writer

| Metric group key | | release-pipeline

| A child of a project, written as:
proj/*:release-pipeline/*

| Project Admin, Maintainer, Owner, Admin

| Release pipeline key | | release-policy

| A child of a project, written as:
proj/*:release-policy/*

| Project Admin, Maintainer, Owner, Admin

| Release policy key | | view

| A child of a project, written as:
proj/*:view/*

| Project Admin, Maintainer, Owner, Admin

| View key | | relay-proxy-config

| A top-level resource, written as:
relay-proxy-config/*

| Admin, Architect, Owner

| Relay Proxy configuration ID | | role

| A child of a project, written as:
role/*

| Admin, Architect, Owner

| Role key | | service-token

| A top-level resource, written as:
service-token/*

| Admin, Architect, Reader

| Service token ID | | team

| A top-level resource, written as:
team/*

| Admin, Architect, Owner

| Team key | | template

| A top-level resource, written as:
template/*

| Admin, Architect, Writer

| Workflow template key | | webhook

| A top-level resource, written as:
webhook/*

| Admin, Architect, Writer

| Webhook ID |

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.