User access

Gloo Mesh provides tools to secure network traffic to your service mesh. To control user access to your Gloo Mesh resources, use Gloo workspaces together with Kubernetes role-based access control (RBAC).

Kubernetes access control determines how users can access and configure Gloo Mesh, Istio, and Kubernetes resources.

Looking for steps on how to use Kubernetes RBAC with Gloo Platform? See Control user access to your resources.

To review the permissions of deployed Gloo components such as the management server and agent, see Gloo component permissions.

Native Kubnernetes RBAC

To manage how users can access and configure those resources, use native Kubernetes role-based access control (RBAC). You can add the custom Gloo Mesh resources to your existing Kubernetes roles or cluster roles. Then, users with those roles get the permission that you grant. For an example, see Example RBAC configuration.

Kubernetes RBAC is not integrated with Gloo Mesh custom resources in any special way. For example, the Gloo Mesh custom resources are not automatically added to any Kubernetes roles. Also, granting users permission to the workspace resource does not automatically give permission to all of the resources within that workspace.

Wondering how Kubernetes RBAC rules might impact a multicluster scenario with your Gloo Mesh resources? Consider the following diagrams.

In this scenario, your cluster users have a role to Cluster A, no role in Cluster B, and a cluster role in Cluster C.

  • Cluster A: The role lets users access all of the Gloo Mesh resources. This access includes exported Gloo Mesh resources, but keep in mind that any configuration changes must be made in the original resource.
  • Cluster B: With no role, the users cannot view, edit, create, or otherwise modify resources in Cluster B. This access prevents the users from even seeing their exported resource in Cluster B.
  • Cluster C: With a cluster role, the users have access to all of the resources, across namespaces.

RBAC access to Gloo Mesh by cluster, scenario 1

In this scenario, your cluster users have a roles in all clusters, but the roles are scoped to specific resources.

  • Cluster A: The role lets users access only route tables. The users can see the exported route table, but not the virtual destination in the cluster. Note that the users cannot modify the route table, because they do not have access to the source route table in Cluster C.
  • Cluster B: The role lets users access only virtual destinations. The users cannot modify the policy in the cluster, even if the policy applies to their virtual destinations.
  • Cluster C: The cluster role lets users access only policies. The users can modify these policies, but cannot see the resources that the policies apply to, such as virtual destinations in the cluster.

RBAC access to Gloo Mesh by cluster, scenario 2

Example RBAC configuration

Use Kubernetes RBAC to control user access to Gloo Mesh resources. One approach might be to modify the default Kubernetes roles for Gloo Mesh resources, such as in the following example.

Curious who does what tasks in Gloo Mesh? Check out the Personas, which can help you decide which Kubernetes roles to assign for specific Gloo Mesh resources.

Looking for steps on how to use Kubernetes RBAC with Gloo Platform? See Control user access to your resources.

Example RBAC roles by persona

Persona Roles Rationale
Pam, Platform Admin The cluster-admin cluster role for all clusters in your setup. To install Gloo Mesh Enterprise and Istio in each cluster. Also, to add users to the clusters.
Arjay, App Owner The cluster-admin cluster role for the cluster or admin or edit role for the namespace that has the workspace settings resource. To update the workspace settings to control importing and exporting. Also, to help manage any Gloo Mesh resources that the team wants to export or import.
Oliver, Operator The admin or edit role for each namespace he is responsible for operating. To create Gloo Mesh resources such as policies for the namespace. Consider giving the view role to the namespace with the workspace settings, so that the operator can review what resources are imported from other workspaces, if any.
Alice, App Developer The edit role for each namespace where she needs to deploy her app. To create Kubernetes resources such as a Deployment and Service, or Gloo Mesh resources such as a Route Table. Consider giving the view role to the namespace with the workspace settings, so that the developer can review what resources are imported from other workspaces, if any.