Before you begin

  1. Add the Gloo custom resource definitions (CRDs) to all of your Kubernetes clusters by following the quickstart or Helm install guides.
  2. Optional: Make sure that the user or group that you want to grant access to has the proper permissions from your cloud provider. For more information, check your cloud provider identity and access management (IAM) documentation.

Gloo API groups and resources for roles

Refer to the following examples for the Gloo API groups and resources that you can add to rules in Kubernetes RBAC roles or cluster roles. The examples are organized by the verbs that are allowed in the default Kubernetes Admin, Edit, and View roles.

To list the Gloo resources, their related API groups, and possible verbs, run the following command.

  kubectl api-resources -o wide | grep gloo
  

Set up Kubernetes RBAC for Gloo resources

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

      kubectl api-resources -o wide | grep gloo
      

    Example output:

      ...
    NAME                              SHORTNAMES   APIVERSION                             NAMESPACED   KIND                             VERBS
    dashboards                                     admin.gloo.solo.io/v2                  true         Dashboard                        [delete deletecollection get list patch create update watch]
    gatewaylifecyclemanagers          glm          admin.gloo.solo.io/v2                  true         GatewayLifecycleManager          [delete deletecollection get list patch create update watch]
    istiolifecyclemanagers            ilm          admin.gloo.solo.io/v2                  true         IstioLifecycleManager            [delete deletecollection get list patch create update watch]
    kubernetesclusters                kc           admin.gloo.solo.io/v2                  true         KubernetesCluster                [delete deletecollection get list patch create update watch]
    workspaces                        ws           admin.gloo.solo.io/v2                  true         Workspace                        [delete deletecollection get list patch create update watch]
    workspacesettings                 wss          admin.gloo.solo.io/v2                  true         WorkspaceSettings                [delete deletecollection get list patch create update watch]
    certificaterequests               cr           internal.gloo.solo.io/v2               true         CertificateRequest               [delete deletecollection get list patch create update watch]
    discoveredcnis                    dcni         internal.gloo.solo.io/v2               true         DiscoveredCNI                    [delete deletecollection get list patch create update watch]
    discoveredgateways                dg           internal.gloo.solo.io/v2               true         DiscoveredGateway                [delete deletecollection get list patch create update watch]
    issuedcertificates                ic           internal.gloo.solo.io/v2               true         IssuedCertificate                [delete deletecollection get list patch create update watch]
    meshes                                         internal.gloo.solo.io/v2               true         Mesh                             [delete deletecollection get list patch create update watch]
    podbouncedirectives               pbd          internal.gloo.solo.io/v2               true         PodBounceDirective               [delete deletecollection get list patch create update watch]
    xdsconfigs                        xc           internal.gloo.solo.io/v2               true         XdsConfig                        [delete deletecollection get list patch create update watch]
    ...
      
  2. Optional: Get the details of an existing role or cluster role to modify, such as the default Kubernetes cluster roles admin, edit, and view.

  3. Create or open the existing configuration file. In the rules section, add a stanza for the Gloo resources that you want to control permissions for. Use the API group, resource name, and verbs that you previously retrieved. For a full list, see Gloo API groups and resources. The following example creates a view-only role for Gloo admin resources.

      kubectl apply -f - <<EOF
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      namespace: gloo-mesh
      name: gloo-view
    rules:
    - apiGroups:
      - admin.gloo.solo.io
      resources:
      - dashboards
      - gatewaylifecyclemanagers
      - istiolifecyclemanagers
      - kubernetesclusters
      - workspaces
      - workspacesettings
      verbs:
      - get
      - list
      - watch
    EOF
      
  4. Create a service account in the same namespace as your role to test permissions.

      kubectl create serviceaccount gloo-rbac-service-account -n gloo-mesh
      
  5. Create or a role binding or cluster role binding that maps the user or service account as a subject for the role or cluster role that you updated. The following example creates a role binding for the service account that you created in the previous step. For more information, see the Kubernetes docs.

      kubectl apply -f - <<EOF
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: gloo-view-role-binding
      namespace: gloo-mesh
    subjects:
    - namespace: gloo-mesh 
      kind: ServiceAccount
      name: gloo-rbac-service-account
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: gloo-view
    EOF
      
  6. Check the permissions that the service account has.

  7. Verify that the service account can get the resources.

    1. Get and decode the token from the secret for the service account.

        kubectl get secrets  -n gloo-mesh $(kubectl get serviceaccount gloo-rbac-service-account -n gloo-mesh -o=jsonpath='{.secrets[0].name}') -o=jsonpath='{.data.token}' | base64 -D
        
    2. Save the token output of the previous step as an environment variable.

        export SA_TOKEN=<ey...>
        
    3. Get the cluster endpoint for API access.

        kubectl get endpoints | grep kubernetes
        

      Example output:

        kubernetes   34.xx.xxx.xxx:443   1d
        
    4. Save the cluster endpoint without the port as an environment variable.

        export CLUSTER_ENDPOINT=<34.xx.xxx.xxx>
        
    5. Send some curl requests to the cluster endpoint with the service account token. Note that some succeed and some fail based on the permissions of the service account.

        curl -k  https://$CLUSTER_ENDPOINT/apis/admin.gloo.solo.io/v2/gatewaylifecyclemanagers -H "Authorization: Bearer $SA_TOKEN"
      curl -k  https://$CLUSTER_ENDPOINT/apis/admin.gloo.solo.io/v2/namespaces/gloo-mesh/gatewaylifecyclemanagers -H "Authorization: Bearer $SA_TOKEN"
      curl -k  https://$CLUSTER_ENDPOINT/apis/internal.gloo.solo.io/v2/namespaces/gloo-mesh/discoveredgateways -H "Authorization: Bearer $SA_TOKEN"
        

      Example output:

      • The first request fails because the service account does not have permissions to list admin resources for the entire cluster.
      • The second request succeeds because the service account can list Gloo admin resources in the gloo-mesh namespace.
      • The third request fails because the service account cannot list Gloo internal resources such as DiscoveredGateways.
  8. Optional: Clean up the resources that you created.

      kubectl delete -n gloo-mesh role gloo-view
    kubectl delete -n gloo-mesh rolebinding gloo-view-role-binding
    kubectl delete -n gloo-mesh serviceaccount gloo-rbac-service-account