Role-based access control

Uses: Kong Mesh

Role-Based Access Control (RBAC) lets you restrict access to resources and actions to specified users or groups, based on user roles.

How RBAC works

Kong Mesh provides two resources to implement RBAC:

  • AccessRole specifies kinds of access and resources to which access is granted. Note that access is defined only for write operations. Read access is available to all users.
  • AccessRoleBinding lists users and the access roles that are assigned to them.

AccessRole

AccessRole defines a role that is assigned separately to users. It is global-scoped, which means it is not bound to a mesh.

Important: Granting access actions without binding them to specific resource types provides full access, including to Secrets and GlobalSecrets, posing security risks. For example, an AccessRole with access: ["CREATE", "UPDATE", "DELETE"] and no defined types allows modifying any resource, including secrets. Even without GENERATE_DATAPLANE_TOKEN, GENERATE_USER_TOKEN, GENERATE_ZONE_CP_TOKEN, or GENERATE_ZONE_TOKEN, the user can retrieve secrets and use them to generate tokens manually. To prevent this, always bind access actions to specific resource types. Instead of unrestricted access, explicitly define allowed types, such as types: ["MeshHTTPRoute", "MeshTCPRoute", "MeshTrace"], to ensure the role can only manage those resources and not secrets or other sensitive data.

AccessRoleBinding

AccessRoleBinding assigns a set of AccessRoles to a list of subjects (users or groups). Because these bindings are global in scope, they apply across all meshes, allowing centralized management of permissions.

Restricting the default AccessRoleBinding

Important: By default, Kong Mesh assigns the admin role to everyone in the mesh-system:authenticated and mesh-system:unauthenticated groups. This means every user automatically gets admin rights, even if you create a custom binding for them, they will also inherit the default admin role.

To limit admin privileges to a specific group, update the default binding. For example, to grant admin rights only to members of the mesh-system:admin group, replace the default binding with the following:

Example RBAC roles

Let’s go through example roles in the organization that can be created using Kong Mesh RBAC.

Kong Mesh operator (admin) role

Mesh operator is a part of infrastructure team responsible for Kong Mesh deployment.

This way Kong Mesh operators can execute any action.

Note: This role is automatically created on the start of the Control Plane.

Service owner role

Service owner is a part of team responsible for given Service. Let’s take a backend Service as an example.

  • Modify MeshRateLimit and MeshTrafficPermission that allows/restricts access to the backend Service. This changes the configuration of the Data Plane proxy that implements the backend Service.
  • Modify connection policies (MeshHTTPRoute,MeshTCPRoute, MeshHealthCheck, MeshCircuitBreaker, MeshFaultInjection, MeshRetry, MeshTimeout, MeshRateLimit, MeshAccessLog) that matches the backend Service that connects to other Services. This changes the configuration of the Data Plane proxy that implements the backend Service.
  • Modify connection policies that matches any Service that consumes backend Service. This changes the configuration of Data Plane proxies that are connecting to the backend, but the configuration only affects connections to the backend Service. It’s useful because the Service owner of the backend knows what (MeshTimeout, MeshHealthCheck) should be applied when communicating with their Service.
  • Modify the MeshTrace or MeshProxyPatch that matches the backend Service. This changes the configuration of the Data Plane proxy that implements the backend Service.

Note: When giving users UPDATE permission, remember to add UPDATE permission to all selectors they can switch between. For example, if a user only has access to sources selector, they won’t be able to update policy with destinations selector or new targetRef selectors. Likewise, when a user only has access to the targetRef kind MeshService, they won’t be able to update the policy to use a different targetRef kind.

Observability operator role

We may also have an infrastructure team which is responsible for the logging/metrics/tracing systems in the organization. Currently, those features are configured on Mesh, MeshAccessLog, and MeshTrace objects.

This way an observability operator can:

  • Modify MeshAccessLog and MeshTrace in any mesh
  • Modify any Mesh

Single Mesh operator role

Kong Mesh lets us segment the deployment into many logical service meshes configured by Mesh object. We may want to give access to one specific Mesh and all objects connected with this Mesh.

This way all observability operator can:

  • Modify all resources in the demo mesh
  • Modify demo Mesh object.

Kubernetes RBAC

Kubernetes provides their own RBAC system, but it’s not sufficient to cover use cases for several reasons:

  • You cannot restrict access to resources of specific Mesh
  • You cannot restrict access based on the content of the policy

Kong Mesh RBAC works on top of Kubernetes RBAC. For example, to restrict the access for a user to modify MeshTrafficPermission for the backend Service, they need to be able to create MeshTrafficPermission in the first place.

The subjects in AccessRoleBinding are compatible with Kubernetes users and groups. Kong Mesh RBAC on Kubernetes is implemented using Kubernetes Webhook when applying resources. This means you can only use Kubernetes users and groups for CREATE, DELETE and UPDATE access. GENERATE_DATAPLANE_TOKEN, GENERATE_USER_TOKEN, GENERATE_ZONE_CP_TOKEN, GENERATE_ZONE_TOKEN are used when interacting with Kong Mesh API Server, in this case you need to use the user token.

Default role

Kong Mesh creates an admin AccessRole that allows every action.

In Kong Mesh 2.6.x or later, the default AccessRoleBinding assigns this role to every authenticated and unauthenticated user.

To restrict access to admin only, change the default AccessRole policy:

Example RBAC configuration

Multi-zone RBAC

In a multi-zone setup, AccessRole and AccessRoleBinding are not synchronized between the global Control Plane and the zone Control Plane.

Wildcard tag value matching v1.9.1+

Note: This feature currently only works with “Source and Destination” selectors. This limitation restricts using newer policy types like MeshTrafficPermission, MeshAccessLog, or MeshHTTPRoute.

You can perform partial tag value matching using * wildcards.

For example, the following role:

would allow a subject to create the following resource:

FAQs

If you remove the default AccessRoleBinding and AccessRole, you might find yourself locked out and unable to edit any resources. If you encounter this situation, you can regain access to the cluster by following these steps:

  1. Configure the control-plane by setting the: KUMA_ACCESS_TYPE environment variable to static, and then restart the control-plane.
  2. Create the default AccessRoleBinding and AccessRole (as described in the default section), or add new groups if necessary.
  3. Remove the KUMA_ACCESS_TYPE environment variable for the control-plane and restart the control-plane.
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!