Before you begin

  1. Add the Gloo custom resource definitions (CRDs) to all of your Kubernetes clusters by following the getting started or an advanced installation guide.
  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.
  3. Optional: Review how Kubernetes RBAC works.

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
    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. 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 policies and networking resources, but not for admin resources.

      kubectl apply -f - <<EOF
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      namespace: gloo-mesh
      name: gloo-view
    rules:
    - apiGroups:
      - extensions.policy.gloo.solo.io
      resources:
      - wasmdeploymentpolicies
      verbs:
      - get
      - list
      - watch
    - apiGroups:
      - networking.gloo.solo.io
      resources:
      - externalendpoints
      - externalservices
      - routetables
      - virtualdestinations
      - virtualgateways
      verbs:
      - get
      - list
      - watch
    - apiGroups:
      - observability.policy.gloo.solo.io
      resources:
      - accesslogpolicies
      verbs:
      - get
      - list
      - watch
    - apiGroups:
      - resilience.policy.gloo.solo.io
      resources:
      - connectionpolicies
      - failoverpolicies
      - faultinjectionpolicies
      - outlierdetectionpolicies
      - retrytimeoutpolicies
      verbs:
      - get
      - list
      - watch
    - apiGroups:
      - security.policy.gloo.solo.io
      resources:
      - accesspolicies
      - corspolicies
      - csrfpolicies
      - extauthpolicies
      - jwtpolicies
      - wafpolicies
      verbs:
      - get
      - list
      - watch
    - apiGroups:
      - trafficcontrol.policy.gloo.solo.io
      resources:
      - headermanipulationpolicies
      - mirrorpolicies
      - proxyprotocolpolicies
      - ratelimitclientconfigs
      - ratelimitpolicies
      - transformationpolicies
      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/resilience.policy.gloo.solo.io/v2/failoverpolicies -H "Authorization: Bearer $SA_TOKEN"
      curl -k  https://$CLUSTER_ENDPOINT/apis/resilience.policy.gloo.solo.io/v2/namespaces/gloo-mesh/failoverpolicies -H "Authorization: Bearer $SA_TOKEN"
      curl -k  https://$CLUSTER_ENDPOINT/apis/admin.gloo.solo.io/v2/namespaces/gloo-mesh/workspaces -H "Authorization: Bearer $SA_TOKEN"
        

      Example output:

      • The first request fails because the service account does not have permissions to list failover policies for the entire cluster.
      • The second request succeeds because the service account can list Gloo failover policies in the gloo-mesh namespace.
      • The third request fails because the service account cannot list Gloo admin resources such as workspaces.
  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