This topic shows some examples of different roles and policies you can implement with policy statements for roles, integrations access, and Relay Proxy access.
LaunchDarkly provides several preset roles which include access to common sets of features. Customers on select plans can update these presets or create their own roles. If you are looking for example roles or policies, we recommend that you start by examining the preset organization and project roles provided by LaunchDarkly. You can also add policy statements to these roles, if the permissions they provide are not quite what works best for your organization. To learn more, read Member role concepts, Organization roles, and Project roles.
Use these sets of policy statements as a starting point for creating or updating roles in your account.
One way to organize access to flags is by adding flags to a view, which is a resource to logically group flags within a project. For example, you can create “frontend” and “backend” views to organize flags within your project, and separate access to flags in those views.
This policy allows access to all actions on flags in the “frontend” view in the “default” project. You can copy and modify this example to suit your needs:
You can also modify this policy to specify the project and view using role attributes. This means you can reuse this role for different members working on different projects and views:
In some cases, policies in which you specify the view using role attributes can only be created in the advanced editor. To learn more, read Use views in complex policy statements.
If you use views to restrict access to sets of flags or other resources, it may be helpful to require that those resources are associated with a view. One way to enforce this, for example, is to create a role that only allows the createFlag action within a particular view. For example, if you normally restrict flag creation to certain roles, you could update the policy statements for those roles to include a specific view.
Here’s how:
When a member creates a feature flag, AgentControl config, or segment, they can associate it with multiple views in a single request. A createFlag statement scoped to one view does not prevent a member from listing additional views in the same API call. This means that a member may be able to add a flag to a view that they do not have access to, as long as they are also adding it to a view they do have permission to add flags to. Access to the flag after it exists is still governed by your other policy statements.
To learn more about views, read Views.
This example policy uses the {property:value} pattern to deny actions on environments based on whether or not they are critical environments. You can mark any environment as critical when you create or update it. Production environments default to being marked as critical.
To manage environments based on the critical property, you must specify the property-based selector as part of the modifiers for the environment resource. Limiting resources to "proj/*:env/*;{critical:true}" accomplishes this.
Copy this policy and make any modifications to it to suit your needs:
This example policy allows members of the Ops team to toggle on or off any flags in the production environment. They may not change percentage rollouts or targeting rules, or manage any environments or projects.
Copy this policy and make any modifications to it to suit your needs:
The policy below allows all actions to be done to a single specified flag, flag-1.
For a complete list of flag actions, read Feature flag actions.
Copy this policy and make any modifications to it to suit your needs:
The policy below allows access only to a project a flag is in, and allows you to perform actions on that flag. In this example, both the project and the flag are specified using role attributes. When you assign this role to a member or team, you are prompted to fill in the projectKey and flagKey referenced in this role. This means you can reuse this role for different members working on different projects and flags.
Copy this policy and make any modifications to it to suit your needs:
This policy allows using only these actions in the production environment:
updateFlagVariationsupdateTagsThis means you can take all other actions in any other non-production environment. In this example, the environment is set to the production environment, but the project is specified using a role attribute. When you assign this role to a member or team, you are prompted to fill in the projectKey referenced in this role. This means you can reuse this role for different members working on different projects.
Copy this policy and make any modifications to it to suit your needs:
In this example, the policy allows specific flag actions in one project, all segment actions in all projects, and all metric actions in all projects. The particular project is specified using a role attribute. When you assign this role to a member or team, you are prompted to fill in the projectKey referenced in this role.
Copy this policy and make any modifications to it to suit your needs:
In the next example, the environment key production represents the account’s production environment in all projects. This policy denies the member from modifying any feature flags in production:
You can also name an “inverse” set of resources by using notResources in a statement. notResources explicitly allows all actions to feature flags across all environments except an environment you specify.
In the example below, the combination of notResources and the allow effect gives access to all environments except the production environment.
Here’s how:
Unlike the LaunchDarkly-provided preset roles, you cannot edit or view policy details of the base roles in the LaunchDarkly user interface. The sections below show the policy details for these roles. You can copy and modify these Reader, Writer, Admin, and No access role templates for your own roles if needed.
Copy this Reader base role and make any modifications to it to suit your needs:
Because permissions are set to deny by default, you must explicitly allow actions for the Writer role. The code snippet below is a replication of LaunchDarkly’s Writer base role. You can copy it and make adjustments as needed.
Copy this Writer base role and make any modifications to it to suit your needs:
Because permissions are set to deny by default, you must explicitly allow actions for the Admin role. The code snippet below is a replication of LaunchDarkly’s Admin base role. You can copy it and make adjustments as needed.
Copy this Admin base role and make any modifications to it to suit your needs:
Permissions are set to deny by default. In other words, by default roles cannot take any actions on any resources. You must create a policy that provides the level of access you prefer. An empty policy is equivalent to the Member preset role or the No access base role.