Role-Based Access Control (RBAC) lets you restrict access to resources and actions to specified users or groups, based on user roles.
Role-based access control
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 definedtypes
allows modifying any resource, including secrets. Even withoutGENERATE_DATAPLANE_TOKEN
,GENERATE_USER_TOKEN
,GENERATE_ZONE_CP_TOKEN
, orGENERATE_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 astypes: ["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 themesh-system:authenticated
andmesh-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
andMeshTrafficPermission
that allows/restricts access to the backend Service. This changes the configuration of the Data Plane proxy that implements thebackend
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 thebackend
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
orMeshProxyPatch
that matches the backend Service. This changes the configuration of the Data Plane proxy that implements thebackend
Service.
Note: When giving users
UPDATE
permission, remember to addUPDATE
permission to all selectors they can switch between. For example, if a user only has access tosources
selector, they won’t be able to update policy withdestinations
selector or newtargetRef
selectors. Likewise, when a user only has access to thetargetRef
kindMeshService
, they won’t be able to update the policy to use a differenttargetRef
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
andMeshTrace
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:
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
, orMeshHTTPRoute
.
You can perform partial tag value matching using *
wildcards.
For example, the following role:
would allow a subject to create the following resource:
FAQs
What should I do if I’ve locked myself out?
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:
-
Configure the control-plane by setting the:
KUMA_ACCESS_TYPE
environment variable tostatic
, and then restart the control-plane. - Create the default
AccessRoleBinding
andAccessRole
(as described in the default section), or add new groups if necessary. - Remove the
KUMA_ACCESS_TYPE
environment variable for the control-plane and restart the control-plane.