Role-based access control

Uses: Kong Mesh

The lack of targetRef, from, or to means that a user can specify anything in this section. For example, the when element with a specific from section allows the user to pick anything for targetRef in the policy.

If the policy contains multiple to elements, you must specify an RBAC qualifier for every single to element.

apiVersion: kuma.io/v1alpha1
kind: AccessRole
metadata:
  name: role-1
spec:
  rules:
  - types: ["TrafficPermission", "TrafficRoute", "Mesh"] # list of Kuma resource kinds to which access is granted. If empty, then access is granted to all kinds
    names: ["res-1"] # list of allowed names of types to which access is granted. If empty, then access is granted to resources regardless of the name.
    mesh: default # Mesh within which the access to resources is granted. It can only be used with the Mesh-scoped resources.
    access: ["CREATE", "UPDATE", "DELETE", "GENERATE_DATAPLANE_TOKEN", "GENERATE_USER_TOKEN", "GENERATE_ZONE_CP_TOKEN", "GENERATE_ZONE_TOKEN"] # an action that is bound to a type.
    when: # a set of qualifiers to receive access. Only one of them needs to be fulfilled to receive an access
    - sources: # a condition on sources section in connection policies (like TrafficRoute or HealthCheck). If missing, then all sources are allowed
        match:
          kuma.io/service: web
      destinations: # a condition on destinations section in connection policies (like TrafficRoute or HealthCheck). If missing, then all destinations are allowed
        match:
          kuma.io/service: backend
    - selectors: # a condition on selectors section in dataplane policies (like TrafficTrace or ProxyTemplate).
        match:
          kuma.io/service: web
    - dpToken: # a condition on generate dataplane token.
        tags:
        - name: kuma.io/service
          value: web

Copied!

type: AccessRole
name: role-1
rules:
- types: ["TrafficPermission", "TrafficRoute", "Mesh"] # list of Kuma resource types to which access is granted. If empty, then access is granted to all types
  names: ["res-1"] # list of allowed names of types to which access is granted. If empty, then access is granted to resources regardless of the name.
  mesh: default # Mesh within which the access to resources is granted. It can only be used with the Mesh-scoped resources.
  access: ["CREATE", "UPDATE", "DELETE", "GENERATE_DATAPLANE_TOKEN", "GENERATE_USER_TOKEN", "GENERATE_ZONE_CP_TOKEN", "GENERATE_ZONE_TOKEN"] # an action that is bound to a type.
  when: # a set of qualifiers to receive access. Only one of them needs to be fulfilled to receive an access
  - sources: # a condition on sources section in connection policies (like TrafficRoute or HealthCheck). If missing, then all sources are allowed
      match:
        kuma.io/service: web
    destinations: # a condition on destinations section in connection policies (like TrafficRoute or HealthCheck). If missing, then all destinations are allowed
      match:
        kuma.io/service: backend
  - selectors: # a condition on selectors section in dataplane policies (like TrafficTrace or ProxyTemplate).
      match:
        kuma.io/service: web
  - dpToken: # a condition on generate dataplane token.
      tags:
      - name: kuma.io/service
        value: web

Copied!

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.

apiVersion: kuma.io/v1alpha1
kind: AccessRoleBinding
metadata:
  name: binding-1
spec:
  subjects:
  - type: User
    name: john.doe@example.com
  - type: Group
    name: team-a
  roles:
  - role-1

Copied!

type: AccessRoleBinding
name: binding-1
subjects:
- type: User
  name: john.doe@example.com
- type: Group
  name: team-a
roles:
- role-1

Copied!

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:

apiVersion: kuma.io/v1alpha1
kind: AccessRoleBinding
metadata:
  name: default
spec:
  subjects:
  - type: Group
    name: mesh-system:admin
  # The `system:serviceaccounts:kube-system` group is required by Kubernetes controllers to manage Kong Mesh 
  # resources, for example, cleaning up Data Plane objects when a namespace is removed.
  - type: Group
    name: system:serviceaccounts:kube-system
  roles:
  - admin

Copied!

type: AccessRoleBinding
name: default
subjects:
- type: Group
  name: mesh-system:admin
roles:
- admin

Copied!

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.

apiVersion: kuma.io/v1alpha1
kind: AccessRole
metadata:
  name: admin
spec:
  rules:
  - access: ["CREATE", "UPDATE", "DELETE", "GENERATE_DATAPLANE_TOKEN", "GENERATE_USER_TOKEN", "GENERATE_ZONE_CP_TOKEN", "GENERATE_ZONE_TOKEN"]

Copied!

type: AccessRole
name: admin
rules:
- access: ["CREATE", "UPDATE", "DELETE", "GENERATE_DATAPLANE_TOKEN", "GENERATE_USER_TOKEN", "GENERATE_ZONE_CP_TOKEN", "GENERATE_ZONE_TOKEN"]

Copied!

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.

type: AccessRole
name: backend-owner
rules:
- mesh: default
  types: ["MeshTrafficPermission", "MeshRateLimit"]
  access: ["CREATE", "DELETE", "UPDATE"]
  when:
  - targetRef:
      kind: MeshService
      name: backend
- mesh: default
  types: ["MeshHTTPRoute", "MeshTCPRoute", "MeshHealthCheck", "MeshCircuitBreaker", "MeshFaultInjection", "MeshRetry", "MeshTimeout", "MeshAccessLog"]
  access: ["CREATE", "DELETE", "UPDATE"]
  when:
  - targetRef:
      kind: Mesh
    from:
      targetRef:
        kind: MeshSubset
        tags:
          kuma.io/service: backend
  - targetRef:
      kind: Mesh
    to:
      targetRef:
        kind: MeshService
        name: backend
- mesh: default
  types: ["MeshTrace", "MeshProxyPatch"]
  access: ["CREATE", "DELETE", "UPDATE"]
  when:
  - targetRef:
      kind: MeshService
      name: backend

Copied!

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.

apiVersion: kuma.io/v1alpha1
kind: AccessRole
metadata:
  name: observability-operator
spec:
  rules:
  - mesh: '*'
    types: ["MeshAccessLog", "MeshTrace"]
    access: ["CREATE", "DELETE", "UPDATE"]
  - types: ["Mesh"]
    access: ["CREATE", "DELETE", "UPDATE"]

Copied!

type: AccessRole
name: observability-operator
rules:
- mesh: '*'
  types: ["MeshAccessLog", "MeshTrace"]
  access: ["CREATE", "DELETE", "UPDATE"]
- types: ["Mesh"]
  access: ["CREATE", "DELETE", "UPDATE"]

Copied!

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.

apiVersion: kuma.io/v1alpha1
kind: AccessRole
metadata:
  name: demo-mesh-operator
spec:
  rules:
  - mesh: demo
    access: ["CREATE", "DELETE", "UPDATE"]
  - types: ["Mesh"]
    names: ["demo"]
    access: ["CREATE", "DELETE", "UPDATE"]

Copied!

type: AccessRole
name: demo-mesh-operator
rules:
- mesh: demo
  access: ["CREATE", "DELETE", "UPDATE"]
- types: ["Mesh"]
  names: ["demo"]
  access: ["CREATE", "DELETE", "UPDATE"]

Copied!

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.

apiVersion: kuma.io/v1alpha1
kind: AccessRole
metadata:
  name: admin
spec:
  rules:
  - access: ["CREATE", "UPDATE", "DELETE", "GENERATE_DATAPLANE_TOKEN", "GENERATE_USER_TOKEN", "GENERATE_ZONE_CP_TOKEN", "GENERATE_ZONE_TOKEN"]
---
apiVersion: kuma.io/v1alpha1
kind: AccessRoleBinding
metadata:
  name: default
spec:
  subjects:
  - type: Group
    name: mesh-system:authenticated
  - type: Group
    name: mesh-system:unauthenticated
  - type: Group
    name: system:authenticated
  - type: Group
    name: system:unauthenticated
  roles:
  - admin

Copied!

type: AccessRole
name: admin
rules:
- access: ["CREATE", "UPDATE", "DELETE", "GENERATE_DATAPLANE_TOKEN", "GENERATE_USER_TOKEN", "GENERATE_ZONE_CP_TOKEN", "GENERATE_ZONE_TOKEN"]
---
type: AccessRoleBinding
name: default
subjects:
- type: Group
  name: mesh-system:authenticated
- type: Group
  name: mesh-system:unauthenticated
roles:
- admin

Copied!

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

apiVersion: kuma.io/v1alpha1
kind: AccessRoleBinding
metadata:
  name: default
spec:
  subjects:
  - type: Group
    name: mesh-system:admin
  - type: Group
    name: system:masters
  # The `system:serviceaccounts:kube-system` group is required by Kubernetes controllers to manage Kong Mesh 
  # resources, for example, cleaning up Data Plane objects when a namespace is removed.
  - type: Group
    name: system:serviceaccounts:kube-system
  roles:
  - admin

Copied!

type: AccessRoleBinding
name: default
subjects:
- type: Group
  name: mesh-system:admin
roles:
- admin

Copied!

Example RBAC configuration

The following steps create a new user and restrict the access to only MeshTrafficPermission for the backend Service.

Create a backend-owner Kubernetes user and configure kubectl:

 mkdir -p /tmp/k8s-certs
 cd /tmp/k8s-certs
 openssl genrsa -out backend-owner.key 2048 # generate client key
 openssl req -new -key backend-owner.key -subj "/CN=backend-owner" -out backend-owner.csr # generate client certificate request
 CSR=$(cat backend-owner.csr | base64 | tr -d "\n") && echo "apiVersion: certificates.k8s.io/v1
 kind: CertificateSigningRequest
 metadata:
   name: backend-owner
 spec:
   request: $CSR
   signerName: kubernetes.io/kube-apiserver-client
   usages:
   - client auth" | kubectl apply -f -
 kubectl certificate approve backend-owner
 kubectl get csr backend-owner -o jsonpath='{.status.certificate}'| base64 -d > backend-owner.crt
 kubectl config set-credentials backend-owner \
 --client-key=/tmp/k8s-certs/backend-owner.key \
 --client-certificate=/tmp/k8s-certs/backend-owner.crt \
 --embed-certs=true
 kubectl config set-context backend-owner --cluster=YOUR_CLUSTER_NAME --user=backend-owner

Copied!

Create Kubernetes RBAC to allow backend-owner to manage all MeshTrafficPermission:

 echo "
 ---
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
   name: kuma-policy-management
 rules:
 - apiGroups:
   - kuma.io
   resources:
   - meshtrafficpermissions
   verbs:
   - get
   - list
   - watch
   - create
   - update
   - patch
   - delete
 ---
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
   name: kuma-policy-management-backend-owner
 roleRef:
   apiGroup: rbac.authorization.k8s.io
   kind: ClusterRole
   name: kuma-policy-management
 subjects:
 - kind: User
   name: backend-owner
   apiGroup: rbac.authorization.k8s.io
 " | kubectl apply -f -

Copied!

Change default Kong Mesh RBAC to restrict access to resources by default:

 echo "
 apiVersion: kuma.io/v1alpha1
 kind: AccessRoleBinding
 metadata:
   name: default
 spec:
   subjects:
   - type: Group
     name: mesh-system:admin
   - type: Group
     name: system:masters
   - type: Group
     name: system:serviceaccounts:kube-system
   roles:
   - admin
 " | kubectl apply -f -

Copied!

Create an AccessRole to grant permissions to user backend-owner to modify MeshTrafficPermission only for the backend Service:

 echo '
 ---
 apiVersion: kuma.io/v1alpha1
 kind: AccessRole
 metadata:
   name: backend-owner
 spec:
   rules:
   - types: ["MeshTrafficPermission"]
     mesh: default
     access: ["CREATE", "UPDATE", "DELETE"]
     when:
     - targetRef:
         kind: MeshService
         name: backend
 ---
 apiVersion: kuma.io/v1alpha1
 kind: AccessRoleBinding
 metadata:
   name: backend-owners
 spec:
   subjects:
   - type: User
     name: backend-owner
   roles:
   - backend-owner
 ' | kubectl apply -f -

Copied!

Change the Service to test user access:

 kubectl config use-context backend-owner
 echo "
 apiVersion: kuma.io/v1alpha1
 kind: MeshTrafficPermission
 metadata:
   name: web-to-backend
   namespace: kong-mesh-system
   labels:
     kuma.io/mesh: default
 spec:
   targetRef:
     kind: MeshService
     name: backend
   from:
   - targetRef:
       kind: MeshService
       name: web
     default:
       action: ALLOW
 " | kubectl apply -f -
 # operation should succeed, access to backend Service access is granted

 echo "
 apiVersion: kuma.io/v1alpha1
 kind: MeshTrafficPermission
 metadata:
   name: web-to-backend
   namespace: kong-mesh-system
   labels:
     kuma.io/mesh: default
 spec:
   targetRef:
     kind: MeshService
     name: not-backend # access to this Service is not granted
   from:
   - targetRef:
       kind: MeshService
       name: web
     default:
       action: ALLOW
 " | kubectl apply -f -
 # operation should not succeed

Copied!

The following steps create a new user and restrict the access to only TrafficPermission for the backend Service.

Note: By default, all requests that originate from localhost are authenticated as the admin user in the mesh-system:admin group. For this example to work, you must either run the Control Plane with KUMA_API_SERVER_AUTHN_LOCALHOST_IS_ADMIN set to false or access the Control Plane using a method other than localhost.

Extract the admin token and configure kumactl with the admin:

 export ADMIN_TOKEN=$(curl http://localhost:5681/global-secrets/admin-user-token | jq -r .data | base64 -d)
 kumactl config control-planes add \
 --name=cp-admin \
 --address=https://localhost:5682 \
 --skip-verify=true \
 --auth-type=tokens \
 --auth-conf token=$ADMIN_TOKEN

Copied!

Configure backend-owner:

 export BACKEND_OWNER_TOKEN=$(kumactl generate user-token --valid-for=24h --name backend-owner)
 kumactl config control-planes add \
 --name=cp-backend-owner \
 --address=https://localhost:5682 \
 --skip-verify=true \
 --auth-type=tokens \
 --auth-conf token=$BACKEND_OWNER_TOKEN
 kumactl config control-planes switch --name cp-admin # switch back to admin

Copied!

Change default Kong Mesh RBAC to restrict access to resources by default:

 echo "type: AccessRoleBinding
 name: default
 subjects:
 - type: Group
   name: mesh-system:admin
 roles:
 - admin" | kumactl apply -f -

Copied!

Create Kong Mesh RBAC to only allow the backend-owner to modify MeshTrafficPermission for backend:

 echo '
 type: AccessRole
 name: backend-owner
 rules:
 - types: ["MeshTrafficPermission"]
   mesh: default
   access: ["CREATE", "UPDATE", "DELETE"]
   when:
   - targetRef:
       kind: MeshService
       name: backend
 ' | kumactl apply -f -
 echo '
 type: AccessRoleBinding
 name: backend-owners
 subjects:
 - type: User
   name: backend-owner
 roles:
 - backend-owner' | kumactl apply -f -

Copied!

Change the user and test RBAC:

 kumactl config control-planes switch --name cp-backend-owner
 echo "
 type: MeshTrafficPermission
 mesh: default
 name: web-to-backend
 spec:
   targetRef:
     kind: MeshService
     name: backend
   from:
   - targetRef:
       kind: MeshService
       name: web
     default:
       action: ALLOW
 " | kumactl apply -f -
 # this operation should succeed

 echo "
 type: MeshTrafficPermission
 mesh: default
 name: web-to-backend
 spec:
   targetRef:
     kind: MeshService
     name: not-backend
   from:
   - targetRef:
       kind: MeshService
       name: web
     default:
       action: ALLOW
 " | kumactl apply -f -
 Error: Access Denied (user "backend-owner/mesh-system:authenticated" cannot access the resource)

Copied!

Create a backend-owner Kubernetes user and configure kubectl:

 mkdir -p /tmp/k8s-certs
 cd /tmp/k8s-certs
 openssl genrsa -out backend-owner.key 2048 # generate client key
 openssl req -new -key backend-owner.key -subj "/CN=backend-owner" -out backend-owner.csr # generate client certificate request
 CSR=$(cat backend-owner.csr | base64 | tr -d "\n") && echo "apiVersion: certificates.k8s.io/v1
 kind: CertificateSigningRequest
 metadata:
   name: backend-owner
 spec:
   request: $CSR
   signerName: kubernetes.io/kube-apiserver-client
   usages:
   - client auth" | kubectl apply -f -
 kubectl certificate approve backend-owner
 kubectl get csr backend-owner -o jsonpath='{.status.certificate}'| base64 -d > backend-owner.crt
 kubectl config set-credentials backend-owner \
 --client-key=/tmp/k8s-certs/backend-owner.key \
 --client-certificate=/tmp/k8s-certs/backend-owner.crt \
 --embed-certs=true
 kubectl config set-context backend-owner --cluster=YOUR_CLUSTER_NAME --user=backend-owner

Copied!

Create Kubernetes RBAC to allow backend-owner to manage all TrafficPermission:

 echo "
 ---
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
   name: kuma-policy-management
 rules:
 - apiGroups:
   - kuma.io
   resources:
   - trafficpermissions
   verbs:
   - get
   - list
   - watch
   - create
   - update
   - patch
   - delete
 ---
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
   name: kuma-policy-management-backend-owner
 roleRef:
   apiGroup: rbac.authorization.k8s.io
   kind: ClusterRole
   name: kuma-policy-management
 subjects:
 - kind: User
   name: backend-owner
   apiGroup: rbac.authorization.k8s.io
 " | kubectl apply -f -

Copied!

Change default Kong Mesh RBAC to restrict access to resources by default:

 echo "
 apiVersion: kuma.io/v1alpha1
 kind: AccessRoleBinding
 metadata:
   name: default
 spec:
   subjects:
   - type: Group
     name: mesh-system:admin
   - type: Group
     name: system:masters
   - type: Group
     name: system:serviceaccounts:kube-system
   roles:
   - admin
 " | kubectl apply -f -

Copied!

Create an AccessRole to grant permissions to the backend-owner user to modify TrafficPermission only for the backend Service:

 echo '
 ---
 apiVersion: kuma.io/v1alpha1
 kind: AccessRole
 metadata:
   name: backend-owner
 spec:
   rules:
   - types: ["TrafficPermission"]
     mesh: default
     access: ["CREATE", "UPDATE", "DELETE"]
     when:
     - destinations:
         match:
           kuma.io/service: backend
 ---
 apiVersion: kuma.io/v1alpha1
 kind: AccessRoleBinding
 metadata:
   name: backend-owners
 spec:
   subjects:
   - type: User
     name: backend-owner
   roles:
   - backend-owner
 ' | kubectl apply -f -

Copied!

Change the Service to test user access:

 kubectl config use-context backend-owner
 echo "
 apiVersion: kuma.io/v1alpha1
 kind: TrafficPermission
 mesh: default
 metadata:
   name: web-to-backend
 spec:
   sources:
   - match:
       kuma.io/service: web
   destinations:
   - match:
       kuma.io/service: backend
 " | kubectl apply -f -
 # operation should succeed, access to backend Service access is granted

 echo "
 apiVersion: kuma.io/v1alpha1
 kind: TrafficPermission
 mesh: default
 metadata:
   name: web-to-backend
 spec:
   sources:
   - match:
       kuma.io/service: web
   destinations:
   - match:
       kuma.io/service: not-backend # access to this Service is not granted
 " | kubectl apply -f -
 # operation should not succeed

Copied!

Note: By default, all requests that originates from localhost are authenticated as the admin user belonging to the mesh-system:admin group. For this example to work, you must either run the Control Plane with KUMA_API_SERVER_AUTHN_LOCALHOST_IS_ADMIN set to false or access the Control Plane via a method other than localhost.

Extract admin token and configure kumactl with admin:

 export ADMIN_TOKEN=$(curl http://localhost:5681/global-secrets/admin-user-token | jq -r .data | base64 -d)
 kumactl config control-planes add \
 --name=cp-admin \
 --address=https://localhost:5682 \
 --skip-verify=true \
 --auth-type=tokens \
 --auth-conf token=$ADMIN_TOKEN

Copied!

Configure backend-owner:

 export BACKEND_OWNER_TOKEN=$(kumactl generate user-token --valid-for=24h --name backend-owner)
 kumactl config control-planes add \
 --name=cp-backend-owner \
 --address=https://localhost:5682 \
 --skip-verify=true \
 --auth-type=tokens \
 --auth-conf token=$BACKEND_OWNER_TOKEN
 kumactl config control-planes switch --name cp-admin # switch back to admin

Copied!

Change default Kong Mesh RBAC to restrict access to resources by default:

 echo "type: AccessRoleBinding
 name: default
 subjects:
 - type: Group
   name: mesh-system:admin
 roles:
 - admin" | kumactl apply -f -

Copied!

Create Kong Mesh RBAC to restrict backend-owner to only modify TrafficPermission for backend:

 echo '
 type: AccessRole
 name: backend-owner
 rules:
 - types: ["TrafficPermission"]
   mesh: default
   access: ["CREATE", "UPDATE", "DELETE"]
   when:
   - destinations:
       match:
         kuma.io/service: backend
 ' | kumactl apply -f -
 echo '
 type: AccessRoleBinding
 name: backend-owners
 subjects:
 - type: User
   name: backend-owner
 roles:
 - backend-owner' | kumactl apply -f -

Copied!

Change the user and test RBAC:

 kumactl config control-planes switch --name cp-backend-owner
 echo "
 type: TrafficPermission
 mesh: default
 name: web-to-backend
 sources:
 - match:
     kuma.io/service: web
 destinations:
 - match:
     kuma.io/service: backend
 " | kumactl apply -f -
 # this operation should succeed

 echo "
 type: TrafficPermission
 mesh: default
 name: web-to-backend
 sources:
 - match:
     kuma.io/service: web
 destinations:
 - match:
     kuma.io/service: other
 " | kumactl apply -f -
 Error: Access Denied (user "backend-owner/mesh-system:authenticated" cannot access the resource)

Copied!

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:

apiVersion: kuma.io/v1alpha1
kind: AccessRole
metadata:
  name: role-wildcard
spec:
  rules:
  - types: ["TrafficRoute"]
    mesh: default
    access: ["CREATE", "UPDATE", "DELETE"]
    when:
    - sources:
        match:
          k8s.kuma.io/namespace: orders
      destinations:
        match:
          kuma.io/service: '*_orders_*'

Copied!

type: AccessRole
name: role-wildcard
rules:
- types: ["TrafficRoute"]
  mesh: default
  access: ["CREATE", "UPDATE", "DELETE"]
  when:
  - sources:
      match:
        k8s.kuma.io/namespace: orders
    destinations:
      match:
        kuma.io/service: '*_orders_*'

Copied!

would allow a subject to create the following resource:

apiVersion: kuma.io/v1alpha1
kind: TrafficRoute
metadata:
  name: tr-orders
spec:
  sources:
  - match:
      k8s.kuma.io/namespace: 'orders'
  destinations:
  - match:
      kuma.io/service: web_orders_svc_1000
  - match:
      kuma.io/service: backend_orders_svc_1000
  conf:
    destination:
      kuma.io/service: '*'

Copied!

type: TrafficRoute
mesh: default
name: tr-orders
sources:
- match:
    k8s.kuma.io/namespace: 'orders'
destinations:
- match:
    kuma.io/service: web_orders_svc_1000
- match:
    kuma.io/service: backend_orders_svc_1000
conf:
  destination:
    kuma.io/service: '*'

Copied!

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 to static, and then restart the control-plane.
Create the default AccessRoleBinding and AccessRole (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.

Role-based access control

How RBAC works

AccessRole

AccessRoleBinding

Restricting the default AccessRoleBinding

Example RBAC roles

Kong Mesh operator (admin) role

Service owner role

Observability operator role

Single Mesh operator role

Kubernetes RBAC

Default role

Example RBAC configuration

Multi-zone RBAC

Wildcard tag value matching v1.9.1+

FAQs

Help us make these docs great!

Still need help