Skip to content
Kong Logo | Kong Docs Logo
search
  • We're Hiring!
  • Docs
    • Kong Gateway
    • Kong Konnect
    • Kong Mesh
    • Plugin Hub
    • decK
    • Kubernetes Ingress Controller
    • Insomnia
    • Kuma

    • Docs contribution guidelines
  • Plugin Hub
  • Support
  • Community
  • Kong Academy
Get a Demo Start Free Trial
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Plugin Hub
  • decK
  • Kubernetes Ingress Controller
  • Insomnia
  • Kuma

  • Docs contribution guidelines
  • 3.2.x (latest)
  • 3.1.x
  • 3.0.x
  • 2.8.x
  • 2.7.x
  • 2.6.x
  • Older Enterprise versions (2.1-2.5)
  • Older OSS versions (2.1-2.5)
  • Archive (pre-2.1)
    • Overview of Kong Gateway
      • Version Support Policy
      • Third Party Dependencies
      • Browser Support
    • Stability
    • Release Notes
      • Services
        • Overview
        • Configure Routes with Expressions
      • Upstreams
      • Plugins
      • Routing Traffic
      • Load Balancing
      • Health Checks and Circuit Breakers
      • Kong Performance Testing
    • Glossary
    • Get Kong
    • Services and Routes
    • Rate Limiting
    • Proxy Caching
    • Key Authentication
    • Load-Balancing
      • Overview
        • Overview
        • Deploy Kong Gateway in Hybrid mode
      • DB-less Deployment
      • Traditional
      • Overview
        • Helm
        • OpenShift with Helm
        • kubectl apply
        • Kubernetes Deployment Options
        • Using docker run
        • Build your own Docker images
        • Amazon Linux
        • Debian
        • Red Hat
        • Ubuntu
      • Running Kong as a non-root user
      • Securing the Admin API
      • Using systemd
      • Start Kong Gateway Securely
      • Programatically Creating Admins
      • Enabling RBAC
      • Overview
      • Download your License
      • Deploy Enterprise License
      • Using the License API
      • Monitor Licenses Usage
      • Default Ports
      • DNS Considerations
      • Network and Firewall
      • CP/DP Communication through a Forward Proxy
        • Configure PostgreSQL TLS
        • Troubleshooting PostgreSQL TLS
    • Kong Configuration File
    • Environment Variables
    • Serving a Website and APIs from Kong
      • Overview
      • Prometheus
      • StatsD
      • Datadog
      • Overview
      • Writing a Custom Trace Exporter
      • Tracing API Reference
    • Resource Sizing Guidelines
    • Security Update Process
    • Blue-Green Deployments
    • Canary Deployments
    • Clustering Reference
      • Log Reference
      • Dynamic log level updates
      • Customize Gateway Logs
      • Upgrade Kong Gateway 3.x.x
      • Migrate from OSS to Enterprise
    • Overview
      • Overview
      • Metrics
      • Analytics with InfluxDB
      • Analytics with Prometheus
      • Estimate Analytics Storage in PostgreSQL
      • Overview
      • Getting Started
      • Advanced Usage
        • Overview
        • Environment Variables
        • AWS Secrets Manager
        • Google Secrets Manager
        • Hashicorp Vault
        • Securing the Database with AWS Secrets Manager
      • Reference Format
      • Overview
      • Get Started with Dynamic Plugin Ordering
      • Overview
      • Enable the Dev Portal
      • Publish an OpenAPI Spec
      • Structure and File Types
      • Themes Files
      • Working with Templates
      • Using the Editor
        • Basic Auth
        • Key Auth
        • OIDC
        • Sessions
        • Adding Custom Registration Fields
        • Manage Developers
        • Developer Roles and Content Permissions
        • Authorization Provider Strategy
        • Enable Application Registration
        • Enable Key Authentication for Application Registration
          • External OAuth2 Support
          • Set up Okta and Kong for External Oauth
          • Set up Azure AD and Kong for External Authentication
        • Manage Applications
        • Theme Editing
        • Migrating Templates Between Workspaces
        • Markdown Rendering Module
        • Customizing Portal Emails
        • Adding and Using JavaScript Assets
        • Single Page App in Dev Portal
        • Alternate OpenAPI Renderer
      • SMTP
      • Workspaces
      • Helpers CLI
      • Portal API Documentation
    • Audit Logging
    • Keyring and Data Encryption
    • Workspaces
    • Consumer Groups
    • Event Hooks
    • Configure Data Plane Resilience
    • About Control Plane Outage Management
      • Overview
      • Install the FIPS Compliant Package
      • FIPS 140-2 Compliant Plugins
    • Overview
    • Enable Kong Manager
      • Services and Routes
      • Rate Limiting
      • Proxy Caching
      • Authentication with Consumers
      • Load Balancing
      • Overview
      • Create a Super Admin
      • Workspaces and Teams
      • Reset Passwords and RBAC Tokens
      • Basic Auth
        • Configure LDAP
        • LDAP Service Directory Mapping
        • Configure OIDC
        • OIDC Authenticated Group Mapping
      • Sessions
        • Overview
        • Enable RBAC
        • Add a Role and Permissions
        • Create a User
        • Create an Admin
    • Networking Configuration
    • Workspaces
    • Create Consumer Groups
    • Sending Email
    • Overview
    • File Structure
    • Implementing Custom Logic
    • Plugin Configuration
    • Accessing the Data Store
    • Storing Custom Entities
    • Caching Custom Entities
    • Extending the Admin API
    • Writing Tests
    • (un)Installing your Plugin
      • Overview
      • kong.client
      • kong.client.tls
      • kong.cluster
      • kong.ctx
      • kong.ip
      • kong.jwe
      • kong.log
      • kong.nginx
      • kong.node
      • kong.request
      • kong.response
      • kong.router
      • kong.service
      • kong.service.request
      • kong.service.response
      • kong.table
      • kong.tracing
      • kong.vault
      • kong.websocket.client
      • kong.websocket.upstream
      • Go
      • Javascript
      • Python
      • Running Plugins in Containers
      • External Plugin Performance
    • Overview
        • Overview
        • OpenID Connect with Curity
        • OpenID Connect with Azure AD
        • OpenID Connect with Google
        • OpenID Connect with Okta
        • OpenID Connect with Auth0
        • OpenID Connect with Cognito
      • Authentication Reference
      • Allow Multiple Authentication Plugins
    • Rate Limiting Plugin
      • Add a Body Value
    • GraphQL
      • gRPC Plugins
      • Configure a gRPC service
    • Overview
    • Information Routes
    • Health Routes
    • Tags
    • Debug Routes
    • Services
    • Routes
    • Consumers
    • Plugins
    • Certificates
    • CA Certificates
    • SNIs
    • Upstreams
    • Targets
    • Vaults
    • Keys
    • Licenses
    • Workspaces
    • RBAC
    • Admins
    • Developers
    • Consumer Groups
    • Event Hooks
    • Keyring and Data Encryption
    • Audit Logs
    • kong.conf
    • Injecting Nginx Directives
    • CLI
    • Key Management
    • Performance Testing Framework
    • Router Expressions Language
    • FAQ

github-edit-pageEdit this page

report-issueReport an issue

enterprise-switcher-iconSwitch to OSS

On this page
  • Default roles
  • RBAC in workspaces
    • How RBAC rules work in Kong Gateway
Kong Gateway
3.2.x (latest)
  • Home
  • Kong Gateway
  • Kong Manager
  • Authentication and Authorization
  • Rbac
  • RBAC in Kong Manager

RBAC in Kong Manager

In addition to authenticating admins and segmenting workspaces, Kong Gateway has the ability to enforce Role-Based Access Control (RBAC) for all resources with the use of roles assigned to admins.

As the super admin (or any role with read and write access to the /admins and /rbac endpoints), it is possible to create new roles and customize permissions.

In Kong Manager, RBAC affects how admins are able to navigate through the application.

Default roles

Kong includes Role-Based Access Control (RBAC). Every admin using Kong Manager needs an assigned role based on the resources they have permission to access.

When a super admin starts Kong for the first time, the default workspace includes three default roles: read-only, admin, and super-admin. The three roles have permissions related to every workspace in the cluster.

Similarly, if a role is confined to certain workspaces, the admin assigned to it will not be able to see either the overview or links to other workspaces.

If a role does not have permission to access entire endpoints, the admin assigned to the role will not be able to see the related navigation links.

Important: Although a default admin has full permissions to every endpoint in Kong, only a super admin has the ability to assign and modify RBAC permissions. An admin is not able to modify their own permissions or delimit a super admin’s permissions.

RBAC in workspaces

If RBAC roles and permissions are assigned from within a workspace, they are specific to that workspace. For example, if there are two workspaces, Payments and Deliveries, an admin created in Payments doesn’t have access to any endpoints in Deliveries.

When a super admin creates a new workspace, there are three default roles that mirror the cluster-level roles, and a fourth unique to each workspace: workspace-read-only, workspace-admin, workspace-super-admin, and workspace-portal-admin.

These roles can be viewed in the Teams > Roles tab in Kong Manager.

Important: Any role assigned in the default workspace has permissions to all subsequently created workspaces unless roles in specific workspaces are explicitly assigned. When roles across multiple workspaces are assigned, roles in workspaces other than default take precedent. For example, a super admin assigned to the super-admin role in the default workspace as well as the workspace-read-only role in the ws workspace has RBAC permissions across all workspaces and full permissions to endpoints in workspaces except the ws workspace. The admin only has read-only permissions to endpoints in the ws workspace.

How RBAC rules work in Kong Gateway

Although there are concepts like groups and roles in Kong Gateway, when determining if a user has sufficient permissions to access the endpoint, combinations of workspace and endpoint are collected from roles and groups assigned to a user, being the minimal unit for Kong Gateway to check for permissions. These combinations will be referred to as “rules” in the following paragraphs.

Kong Gateway uses a precedence model, from most specificity to least specificity, to determine if a user has access to an endpoint. For each request Kong Gateway checks for an RBAC rule assigned to the requesting user in the following order:

  • An allow or deny rule against the current endpoint in the current workspace

  • An allow or deny rule against the current endpoint in any workspace (*)

  • An allow or deny rule against any endpoint (*) in the current workspace

  • An allow or deny rule against any endpoint (*) in any workspace (*)

If Kong Gateway finds a matching rule for the current user, endpoint, and workspace it allows or denies the request according to that rule. Once Kong Gateway finds an applicable rule, it stops, and does not continue checking for less specific rules. If no rules are found, the request is denied.

The default admin roles define permissions for any workspace is (*). Kong Gateway stops at the first role, which means any role assigned in the default workspace has permissions to all subsequently created workspaces unless roles in specific workspaces are explicitly assigned. When roles across multiple workspaces are assigned, roles in workspaces other than default take precedent. For example, a user assigned to the super-admin role in the default workspace as well as the workspace-read-only role in the ws workspace has full permissions to endpoints in all workspaces except the ws workspace. The user only has read-only permissions to endpoints in the ws workspace.

Kong Gateway allows you to add negative rules to a role. A negative rule denies actions associated with the endpoint. Meanwhile, a negative rule precedes other non-negative rules while following the above rules.

Thank you for your feedback.
Was this page useful?
  • Kong
    THE CLOUD CONNECTIVITY COMPANY

    Kong powers reliable digital connections across APIs, hybrid and multi-cloud environments.

    • Company
    • Customers
    • Events
    • Investors
    • Careers Hiring!
    • Partners
    • Press
    • Contact
  • Products
    • Kong Konnect
    • Kong Gateway
    • Kong Mesh
    • Get Started
    • Pricing
  • Resources
    • eBooks
    • Webinars
    • Briefs
    • Blog
    • API Gateway
    • Microservices
  • Open Source
    • Install Kong Gateway
    • Kong Community
    • Kubernetes Ingress
    • Kuma
    • Insomnia
  • Solutions
    • Decentralize
    • Secure & Govern
    • Create a Dev Platform
    • API Gateway
    • Kubernetes
    • Service Mesh
Star
  • Terms•Privacy
© Kong Inc. 2023