Kubernetes RBAC

Gloo Mesh provides tools to secure network traffic to your service mesh. But you also need to control user access to your resources. You can use Gloo Mesh 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.

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.

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.

Using Kubernetes RBAC

Before you begin:

To set up Kubernetes RBAC for Gloo Mesh resources:

  1. List the Gloo Mesh resources and their related API groups and possible verbs.

    kubectl api-resources -o wide | grep gloo
    

    Example output:

    ...
    NAME                 SHORTNAMES  APIVERSION                                       NAMESPACED  KIND                VERBS
    workspaces                                     admin.gloo.solo.io/v2                   true         Workspace                        [delete deletecollection get list patch create update watch]
    workspacesettings                              admin.gloo.solo.io/v2                   true         WorkspaceSettings                [delete deletecollection get list patch create update watch]
    routetables                                    networking.gloo.solo.io/v2              true         RouteTable                       [delete deletecollection get list patch create update watch]
    virtualdestinations                            networking.gloo.solo.io/v2              true         VirtualDestination               [delete deletecollection get list patch create update watch]
    virtualgateways                                networking.gloo.solo.io/v2              true         VirtualGateway                   [delete deletecollection get list patch create update watch]
    ...
    
  2. Find the roles and cluster roles that you want to modify. In this example, the default Kubernetes cluster roles admin, edit, and view are used.

    kubectl get roles,clusterroles -A
    
  3. Export the role that you want to modify as a local YAML file.

    
       kubectl get clusterrole $CLUSTER_ROLE -o yaml > $CLUSTER_ROLE.yaml
       
    
       kubectl get role $ROLE -o yaml > $ROLE.yaml
       
  4. Open the YAML file. In the rules section, add a stanza for the Gloo Mesh resources that you want to control permissions for. Use the API group, resource name, and verbs that you previously retrieved, such as in the following examples.

    
       apiVersion: rbac.authorization.k8s.io/v1
       kind: ClusterRole
       rules:
       - apiGroups:
         - admin.gloo.solo.io/v2
         - enterprise.gloo.solo.io/v1
         - extensions.policy.gloo.solo.io/v2
         - networking.gloo.solo.io/v2
         - observability.policy.gloo.solo.io/v2
         - resilience.policy.gloo.solo.io/v2
         - security.policy.gloo.solo.io/v2
         - trafficcontrol.policy.gloo.solo.io/v2
         resources:
         - dashboards
         - extauthservers
         - kubernetesclusters
         - ratelimitserverconfigs
         - ratelimitserversettings
         - roottrustpolicies
         - workspaces
         - workspacesettings
         - authconfigs
         - wasmdeploymentpolicies
         - externalendpoints
         - externalservices
         - routetables
         - virtualdestinations
         - virtualgateways
         - accesslogpolicies
         - failoverpolicies
         - faultinjectionpolicies
         - outlierdetectionpolicies
         - retrytimeoutpolicies
         - accesspolicies
         - corspolicies
         - csrfpolicies
         - extauthpolicies
         - mirrorpolicies
         - ratelimitclientconfigs
         - ratelimitpolicies
         - transformationpolicies
         verbs:
         - create
         - delete
         - deletecollection
         - get
         - patch
         - update
         - watch
       
    
       apiVersion: rbac.authorization.k8s.io/v1
       kind: ClusterRole
       rules:
       - apiGroups:
         - admin.gloo.solo.io/v2
         - enterprise.gloo.solo.io/v1
         - extensions.policy.gloo.solo.io/v2
         - networking.gloo.solo.io/v2
         - observability.policy.gloo.solo.io/v2
         - resilience.policy.gloo.solo.io/v2
         - security.policy.gloo.solo.io/v2
         - trafficcontrol.policy.gloo.solo.io/v2
         resources:
         - dashboards
         - extauthservers
         - kubernetesclusters
         - ratelimitserverconfigs
         - ratelimitserversettings
         - roottrustpolicies
         - workspaces
         - workspacesettings
         - authconfigs
         - wasmdeploymentpolicies
         - externalendpoints
         - externalservices
         - routetables
         - virtualdestinations
         - virtualgateways
         - accesslogpolicies
         - failoverpolicies
         - faultinjectionpolicies
         - outlierdetectionpolicies
         - retrytimeoutpolicies
         - accesspolicies
         - corspolicies
         - csrfpolicies
         - extauthpolicies
         - mirrorpolicies
         - ratelimitclientconfigs
         - ratelimitpolicies
         - transformationpolicies
         verbs:
         - get
         - patch
         - update
         - watch
       
    
       apiVersion: rbac.authorization.k8s.io/v1
       kind: ClusterRole
       rules:
       - apiGroups:
         - admin.gloo.solo.io/v2
         - enterprise.gloo.solo.io/v1
         - extensions.policy.gloo.solo.io/v2
         - networking.gloo.solo.io/v2
         - observability.policy.gloo.solo.io/v2
         - resilience.policy.gloo.solo.io/v2
         - security.policy.gloo.solo.io/v2
         - trafficcontrol.policy.gloo.solo.io/v2
         resources:
         - dashboards
         - extauthservers
         - kubernetesclusters
         - ratelimitserverconfigs
         - ratelimitserversettings
         - roottrustpolicies
         - workspaces
         - workspacesettings
         - authconfigs
         - wasmdeploymentpolicies
         - externalendpoints
         - externalservices
         - routetables
         - virtualdestinations
         - virtualgateways
         - accesslogpolicies
         - failoverpolicies
         - faultinjectionpolicies
         - outlierdetectionpolicies
         - retrytimeoutpolicies
         - accesspolicies
         - corspolicies
         - csrfpolicies
         - extauthpolicies
         - mirrorpolicies
         - ratelimitclientconfigs
         - ratelimitpolicies
         - transformationpolicies
         verbs:
         - get
         - watch
       

  5. Save and apply the updated role to your cluster.

    kubectl apply -f $ROLE.yaml
    
  6. Make sure that the users are subjects in the role binding or cluster role binding for the role that you updated.

  7. Repeat for each cluster in your Gloo Mesh environment.