Gloo provides tools to secure network traffic to the workloads in your cluster. To control user access to Gloo resources, use Gloo workspaces together with Kubernetes role-based access control (RBAC).

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

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 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.

Wondering how Kubernetes RBAC rules might impact a multicluster scenario with your Gloo 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 resources. This access includes exported Gloo 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.
Figure: RBAC access to Gloo by cluster, scenario 1
Figure: RBAC access to Gloo by cluster, scenario 1

In this scenario, your cluster users have a role 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.
Figure: RBAC access to Gloo by cluster, scenario 2
Figure: RBAC access to Gloo by cluster, scenario 2

Example RBAC configuration

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

Example RBAC roles by persona

PersonaRolesRationale
Pam, Platform AdminThe cluster-admin cluster role for all clusters in your setup.To install Gloo Mesh Gateway and Istio in each cluster. Also, to add users to the clusters.
Arjay, App OwnerThe 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 resources that the team wants to export or import.
Oliver, OperatorThe admin or edit role for each namespace he is responsible for operating.To create Gloo 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 DeveloperThe edit role for each namespace where she needs to deploy her app.To create Kubernetes resources such as a Deployment and Service, or Gloo 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.