Manage RBAC roles

Uses: decK

decK can manage Kong Gateway Enterprise Role-Based Access Control (RBAC) configuration using the deck gateway diff, deck gateway sync, and deck gateway dump commands.

decK can’t manage Konnect permissions as they are set at the organization level, rather than the Control Plane level. We recommend terraform-provider-konnect for your Konnect RBAC needs.

RBAC configuration is usually stored separately from all other configuration, and decK provides the --rbac-resources-only flag to ensure that only RBAC resources are in scope when running commands.

RBAC roles accept a list of actions, a wildcard endpoint (for example,/services/*), and if the role is negative or not. A negative RBAC role means that the actions listed are explicitly denied on the endpoint specified, even if allowed by a different permission.

_format_version: "3.0"
rbac_roles:
  - comment: Read access to all endpoints, across all workspaces
    endpoint_permissions:
      - actions:
          - read
        endpoint: "*"
        negative: false
        workspace: "*"
    name: read-only
  - comment: Full access to all endpoints, across all workspaces
    endpoint_permissions:
      - actions:
          - read
          - delete
          - create
          - update
        endpoint: "*"
        negative: false
        workspace: "*"
    name: super-admin

Required permissions for decK

decK uses Kong’s Admin API to communicate with Kong Gateway. If you have RBAC enabled, you need to give decK permissions to perform operations, or use an admin account that has these permissions.

Here are some common endpoints hit by decK for normal operations:

  • GET, POST, PATCH, PUT, DELETE /{entityType} or GET, POST, PATCH, PUT, DELETE /{workspace}/{entityType}: Perform read and write operations on entities.

    decK interacts with entities inside workspaces. See the Entities managed by decK reference for the full list.

    Note that decK also performs operations on entities enabled by plugins, such as /basic-auths, /jwts, and so on.

  • GET /: Get the Kong Gateway version.
  • GET /{workspace}/kong: Get entities in a workspace.
  • GET /{workspace}/workspaces/{entityType}: Check whether the workspace or other entity exists or not.
  • GET /{workspace}/schemas/{entityType}: Retrieves the schema for a specified entity type within a workspace and applies default settings.
  • GET /{workspace}/schemas/plugins/{pluginName}: Retrieves the schema for a specified Plugin within a workspace and applies default settings.
  • POST /workspaces: Create missing workspaces.

To find out which endpoints your instance of decK is hitting, execute any decK command with the --verbose 1 flag. This outputs all of the queries being made. For example, here’s a snippet from deck gateway dump --verbose 1:

...
GET /routes?size=1000 HTTP/1.1
Host: localhost:8001
User-Agent: Go-http-client/1.1
Accept-Encoding: gzip


GET /consumers?size=1000 HTTP/1.1
Host: localhost:8001
User-Agent: Go-http-client/1.1
Accept-Encoding: gzip


GET /mtls-auths?size=1000 HTTP/1.1
Host: localhost:8001
User-Agent: Go-http-client/1.1
Accept-Encoding: gzip


GET /snis?size=1000 HTTP/1.1
Host: localhost:8001
User-Agent: Go-http-client/1.1
Accept-Encoding: gzip
...
Something wrong?

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!