Custom roles

Overview

This topic explains what custom roles are and how to create them.

Custom roles give you precise access control to everything in LaunchDarkly, including feature flags, projects, environments, metrics, and teams, so you can enforce access policies that meet your exact workflow needs.

With custom roles, you can:

• Lock your production environment down to a small set of trusted members
• Allow account members to control feature flags on projects or environments that are designated for their team only
• Allow different permissions at the flag level, such as between experiment flags and operational flags
• Create private projects that only the account members you select can view. To learn more, read Creating private projects with custom roles.

Our custom role system is inspired by AWS Identity and Access Management (IAM). If you're familiar with IAM, there are some similarities.

Each account member must have at least one role. You can assign account members a built-in role or one or more custom roles to give them the exact set of permissions they need. To learn more, read LaunchDarkly's built-in roles.

An account member's initial role is set when they're invited to LaunchDarkly. If not otherwise specified, new account members are assigned the Reader role. An account member with the ability to do so must adjust the member's role to give them more advanced permissions.

The one exception to this is the first account member, the person who created your LaunchDarkly account. This role is granted Owner permissions automatically, because they are required to configure your account completely and add more account members.

Configuring custom role scopes

Custom roles are extremely precise in their scope and targeting. For example, you can define a custom role to allow the recipient of that role to take all actions on only one flag in a project, and also not allow that role recipient to view any other projects.

This level of precision also means you must specifically allow or deny actions for every resource you want the role recipient to be able to take. If you do not specify an action for a resource, that action is set to deny by default.

One method of creating a custom role is to start with a policy that matches permissions for a Reader or Writer role, and modify it.

For templates that match these permission levels, read Example policies.

Using custom roles

Implementing custom roles is a three-step process.

To implement a custom role:

1. Create a custom role.
2. Create a policy for that custom role.
3. Assign the role to the account member or resource who needs it.

Read each topic in this section to learn more about custom roles.

Before creating a custom role, we recommend familiarizing yourself with the concepts that power custom roles. To learn more, read Custom role concepts.

To learn how to create a custom role, read Creating custom roles and policies.