Using the advanced editor

Overview

This topic explains how to access and use the advanced editor to create complex roles and policies. The advanced editor is a tool for experienced LaunchDarkly members who want to create their own roles. You can use it to create roles and policies that are more complex and detailed than those supported by the policy builder.

Create role policies with the advanced editor

To access the advanced editor:

1. Click the gear icon in the left sidenav to view Organization settings.

2. Click Roles in the left sidenav.

3. Click Create role. The New role page appears:

   

4. In the “Edit Policy” panel, click View JSON.

5. (Optional) If you do not wish to use the advanced editor, click Policy builder to return to the graphical policy builder. Continue with the procedure Create policies for roles.

6. Specify the effects, resources, and actions you wish. You can also specify inverse action and resource sets using notActions and notResources respectively.

7. Click Create role.

Syntax for the advanced editor

When you create a policy with the advanced editor, you use a JSON array to specify the policy. Each element in the policy array is a statement represented as a JSON object with three attributes:

When you create a policy with the advanced editor, you can specify resources that the role can or cannot access in the following ways:

• All instances of the resource, for example, all projects:

  All actions on all projects

  1
    [
  2
      {
  3
        "effect": "allow",
  4
        "actions": ["*"],
  5
        "resources": [ "proj/*"]
  6
      }
  7
    ]

• All instances of the resource with a few exceptions, for example, all projects except “Project A”:

  All actions on all projects except Project A

  1
    [
  2
      {
  3
        "effect": "allow",
  4
        "actions": ["*"],
  5
        "notResources": [ "proj/project-a"]
  6
      }
  7
    ]

• Only specific instances of the resource, for example, “Project A,” “Project B,” and “Project C”:

  All actions on Project A, Project B, Project C

  1
    [
  2
      {
  3
        "effect": "allow",
  4
        "actions": ["*"],
  5
        "resources": [ "proj/project-a", "proj/project-b", "proj/project-c"]
  6
      }
  7
    ]

• Only specific instances of the resource, where the instances are specified based on a parameter, called a role attribute. You specify the value of this parameter when you assign the role to a member or team. For example, all projects whose project key will be specified by the parameter developerProjectKey:

  All actions on project specified in developerProjectKey

  1
    [
  2
      {
  3
        "effect": "allow",
  4
        "actions": ["*"],
  5
        "resources": ["proj/${roleAttribute/developerProjectKey}"]
  6
      }
  7
    ]

• Only specific instances of the resource, where the instances have a particular tag. For example, all projects with the “example” tag:

  All actions on projects with tag 'example'

  1
    [
  2
      {
  3
        "effect": "allow",
  4
        "actions": ["*"],
  5
        "resources": [ "proj/*;example"]
  6
      }
  7
    ]

• Only specific instances of the resource, where the instance properties match a particular value, for example, all environments that are marked as critical:

  All actions on critical environments

  1
    [
  2
      {
  3
        "effect": "allow",
  4
        "actions": ["*"],
  5
        "resources": [ "proj/*:env/*;{critical:true}"]
  6
      }
  7
    ]

In the advanced editor, you must use resource keys, not display names. If you use names, the policies will not take effect. The resource keys are case-sensitive. For example, if the production environment of your default project has the key production, then referencing proj/default:env/Production in your policy will not work. Alternatively, you can use role attributes instead of specific resource keys in your policy. To learn more, read Using role scope.

For advanced policy examples, read Example roles and policies.