# Configure RBAC policies

This topic describes how to use role-based access policies (RBAC) to grant or deny team members permissions in the Replicated Vendor Portal.

## About RBAC policies

By default, every team has two policies created automatically: **Admin** and **Read Only**. If you have an Enterprise plan, you will also have the **Sales** and **Support** policies created automatically. These default policies are not configurable. For more information, see [Default RBAC Policies](#default-rbac).

You can configure custom RBAC policies if you are on the Enterprise pricing plan. Creating custom RBAC policies lets you limit which Vendor Portal areas team members can access and control read and read/write privileges by role. For example, you can limit access for the sales team to one application and to specific channels. Or, you can grant only certain users permission to promote releases to your production channels. 

You can also create custom RBAC policies in the Vendor Portal to manage user access and permissions in the Replicated collab repository in GitHub. For more information, see [Manage Access to the Collab Repository](team-management-github-username).

## Default RBAC policies {#default-rbac}

This section describes the default RBAC policies for Vendor Portal teams, depending on the team's Replicated pricing plan.

### Admin

The Admin policy grants read/write permissions to all resources on the team. 

:::note
This policy is automatically created for all plans.
:::

```json
{
  "v1": {
    "name": "Admin",
    "resources": {
      "allowed": [
        "**/*"
      ],
      "denied": []
    }
  }
}
```

### Read only

The Read Only policy grants read permission to all resources on the team except for API tokens.

:::note
This policy is automatically created for all plans.
:::

```json
{
  "v1": {
    "name": "Read Only",
    "resources": {
      "allowed": [
        "**/list",
        "**/read"
      ],
      "denied": [
        "**/*"
      ]
    }
  }
}
```

### Support engineer

The Support Engineer policy grants read access to releases, channels, and application data, and read-write access to customer and license details. It also grants permission to open and triage Replicated support issues, manage Enterprise Portal customer users, and manage the user's own notification subscriptions.

:::note
This policy is automatically created for teams with the Enterprise plan only.
:::

```json
{
  "v1": {
    "name": "Support Engineer",
    "resources": {
      "allowed": [
        "**/read",
        "**/list",
        "platform/app/*/license/**",
        "kots/app/*/license/**",
        "team/support-issues/triage",
        "team/support-issues/write",
        "kots/app/*/enterprise-portal/customer-users/read",
        "kots/app/*/enterprise-portal/customer-user/create",
        "kots/app/*/enterprise-portal/customer-user/login",
        "kots/app/*/enterprise-portal/customer-user/*/delete",
        "team/notifications/subscriptions/create",
        "team/notifications/subscriptions/update",
        "team/notifications/subscriptions/delete"
      ],
      "denied": [
        "**/*"
      ]
    }
  }
}
```

### Sales

The Sales policy grants read-write access to customers and license details. It also grants read-only access to applications, channels, license fields, the activity stream, and Enterprise Portal data. Additionally, it grants the ability to manage notification subscriptions and invite Enterprise Portal customer users.

:::note
This policy is automatically created for teams with the Enterprise plan only.
:::

```json
{
  "v1": {
    "name": "Sales",
    "resources": {
      "allowed": [
        "kots/app/*/read",
        "kots/app/*/channel/*/read",
        "kots/app/*/licensefields/read",
        "kots/app/*/license/**",
        "kots/license/**",
        "team/notifications/subscriptions/read",
        "team/notifications/subscriptions/create",
        "team/notifications/subscriptions/update",
        "team/notifications/subscriptions/delete",
        "team/notifications/types/list",
        "team/notifications/events/read",
        "team/activity-stream/read",
        "kots/app/*/enterprise-portal/**/read",
        "kots/app/*/enterprise-portal/customer-users/read",
        "kots/app/*/enterprise-portal/customer-user/create",
        "kots/app/*/enterprise-portal/customer-user/login"
      ],
      "denied": [
        "**/*"
      ]
    }
  }
}
```

## Configure a custom RBAC policy

To configure a custom RBAC policy:

1. From the Vendor Portal [Team page](https://vendor.replicated.com/team), select **RBAC** from the navigation menu.

1. Do _one_ of the following:

    - Click **Create Policy** from the RBAC page to create a new policy.
    - Click **View policy** to edit an existing custom policy in the list.

      :::important
      When you update an existing RBAC policy to add one or more `team/support-issues` resource, the GitHub role in the Replicated collab repository of every team member that is assigned to that policy and has a GitHub username saved in their account is updated accordingly.
      :::

1. Edit the fields in the policy dialog. In the **Definition** pane, specify the `allow` and `denied` arrays in the resources key to create limits for the role.

   The default policy allows everything and the **Config help** pane displays any errors.

    ![Create RBAC Policy](/images/policy-create.png) 

    - For more information, see [Policy Definition](#policy-definition).
    - For more information about and examples of rule order, see [Rule Order](#rule-order).
    - For a list of resource names, see [RBAC Resource Names](team-management-rbac-resource-names).

1. Click **Create Policy** to create a new policy, or click **Update Policy** to update an existing policy.

   :::note
   Click **Cancel** to exit without saving changes.
   :::

1. To apply RBAC policies to Vendor Portal team members, you can:

    - Assign policies to existing team members
    - Specify a policy when inviting new team members
    - Set a default policy for auto-joining a team

    See [Manage Team Members](team-management).

## Policy definition

Define a policy in a single JSON document:

```
{
  "v1": {
    "name": "Read Only",
    "resources": {
      "allowed": [
        "**/read",
        "**/list"
      ],
      "denied": [
        "**/*"
      ]
    }
  }
}
```

The primary content of a policy document is the resources key. The resources key should contain two arrays, identified as `allowed` and `denied`. Resources in the `allowed` list grant access to users assigned to the policy. Resources in the `denied` list block access.

Resource names are hierarchical, and support wildcards and globs. For a complete list of resource names to use in a policy document, see [RBAC Resource Names](team-management-rbac-resource-names).

When a policy document has conflicting rules, the behavior is predictable. For more information about conflicting rules, see [Rule Order](#rule-order).

### Example: View specific application and channel

  The following policy definition example limits any user with this role to viewing a specific application and a specific channel for that application:

    ```
    {
      "v1": {
        "name": "Policy Name",
        "resources": {
          "allowed": [
            "kots/app/appID/list",
            "kots/app/appID/read",
            "kots/app/appID/channel/channelID/list",
            "kots/app/appID/channel/channelID/read"
          ],
          "denied": []
        }
      }
    }
    ```
  The preceding example uses an application ID and a channel ID to scope the permissions of the RBAC policy. To find your application and channel IDs, do the following:

  - To get the application ID, click **Settings > Show Application ID (Advanced)** in the Vendor Portal.

  - To get the channel ID, click **Channels** in the Vendor Portal. Then click the Release History link for the channel that you want to limit access to. The channel ID displays in your browser URL.

## Rule order

When a resource name appears in both the `allow` and `deny` chains of a policy, defined rules determine which rule applies.

If `denied` is empty, it defaults to a `**/*` rule, unless the `allowed` resources include a `**/*` rule. If a rule exactly conflicts with another rule, the `denied` rule takes precedence.

### Defining precedence using rule specificity
The most specific rule definition is always applied, when compared with less specific rules. The number of asterisks (`**` and `*`) in a rule determines its specificity. A `**` in the rule definition is the least specific, followed by rules with `*`, and finally rules with no wildcards as the most specific.

### Example: No access to stable channel

In the following example, a policy grants access to promote releases to any channel except the Stable channel. It uses the rule pattern `kots/app/[:appId]/channel/[:channelId]/promote`. Note that you specify the channel ID, rather than the channel name. To find the channel ID, go to the Vendor Portal **Channels** page and click the **Settings** icon for the target channel.

```json
{
  "v1": {
    "name": "No Access To Stable Channel",
    "resources": {
      "allowed": [
        "**/*"
      ],
      "denied": [
        "kots/app/*/channel/1eg7CyEofYSmVAnK0pEKUlv36Y3/promote"
      ]
    }
  }
}
```

### Example: View customers only

In the following example, a policy grants access to viewing all customers, but not to creating releases, promoting releases, or creating new customers.

```json
{
  "v1": {
    "name": "View Customers Only",
    "resources": {
      "allowed": [
        "kots/app/*/license/*/read",
        "kots/app/*/license/*/list",
        "kots/app/*/read",
        "kots/app/*/list"
      ],
      "denied": [
        "**/*"
      ]
    }
  }
}
```