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. Use them to enforce access policies that meet your exact 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 Create 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 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. Another 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.

Configure custom role scopes

Custom roles are extremely precise in their scope. 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.

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

This level of precision 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 and templates.

Implement 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 an account member or team.

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. To learn how to create highly specific custom roles from scratch, read Using the advanced editor.