Skip to content
You are viewing the documentation for Solo Enterprise for Istio, formerly known as Gloo Mesh (OSS APIs).

Control user access to your resources

Page as Markdown

Use Kubernetes RBAC to control user access to Gloo resources in your clusters.

Before you begin

  1. Add the Solo Enterprise for Istio custom resource definitions (CRDs) to all of your Kubernetes clusters by following the Get started or the Install with Helm 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.

Solo Enterprise for Istio API groups and resources for roles

Refer to the following examples for the Solo Enterprise for Istio 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 Solo Enterprise for Istio resources, their related API groups, and possible verbs, run the following command.

kubectl api-resources -o wide | grep gloo
rules:
- apiGroups:
  - admin.gloo.solo.io
  resources:
  - dashboards
  - gatewaylifecyclemanagers
  - istiolifecyclemanagers
  - kubernetesclusters
  - workspaces
  - workspacesettings
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
rules:
- apiGroups:
  - admin.gloo.solo.io
  resources:
  - dashboards
  - gatewaylifecyclemanagers
  - istiolifecyclemanagers
  - kubernetesclusters
  - workspaces
  - workspacesettings
  verbs:
  - get
  - list
  - patch
  - update
  - watch
rules:
- apiGroups:
  - admin.gloo.solo.io
  resources:
  - dashboards
  - gatewaylifecyclemanagers
  - istiolifecyclemanagers
  - kubernetesclusters
  - workspaces
  - workspacesettings
  verbs:
  - get
  - list
  - watch

Set up Kubernetes RBAC for Solo Enterprise for Istio resources

  1. List the Solo Enterprise for Istio 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.

    1. Get the name of the existing role that you want to modify.
      kubectl get roles -A
    2. Get the configuration of the role that you want to modify and save it as a local YAML file.
      kubectl get role $ROLE -o yaml > $ROLE.yaml
    1. Get the name of the existing cluster role that you want to modify.
      kubectl get clusterroles -A
    2. Get the configuration of the cluster role that you want to modify and save it as a local YAML file.
      kubectl get clusterrole $CLUSTER_ROLE -o yaml > $CLUSTER_ROLE.yaml

  3. Create or open the existing configuration file. In the rules section, add a stanza for the Solo Enterprise for Istio 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 Solo Enterprise for Istio API groups and resources. The following example creates a view-only role for Solo Enterprise for Istio 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.

    kubectl auth can-i get gatewaylifecyclemanagers --as=system:serviceaccount:gloo-mesh:gloo-rbac-service-account -n gloo-mesh
    kubectl auth can-i get discoveredgateways --as=system:serviceaccount:gloo-mesh:gloo-rbac-service-account -n gloo-mesh
    kubectl auth can-i get gatewaylifecyclemanagers --as=system:serviceaccount:gloo-mesh:gloo-rbac-service-account

    Example output:

    • yes: The service account can get GatewayLifecycleManagers in the gloo-mesh namespace, as expected.
    • no: The service account cannot get DiscoveredGateways in the gloo-mesh namespace, because the role only gives viewer permissions for Solo Enterprise for Istio admin resources, not internal resources.
    • no: The service account cannot get GatewayLifecycleManagers in the default namespace, because the role and role binding are scoped to the gloo-mesh namespace.
    kubectl auth can-i --list --as=system:serviceaccount:gloo-mesh:gloo-rbac-service-account -n gloo-mesh

    Example output:

    Resources                                         Non-Resource URLs                     Resource Names   Verbs
    dashboards.admin.gloo.solo.io                     []                                    []               [get list watch]
    gatewaylifecyclemanagers.admin.gloo.solo.io       []                                    []               [get list watch]
    istiolifecyclemanagers.admin.gloo.solo.io         []                                    []               [get list watch]
    kubernetesclusters.admin.gloo.solo.io             []                                    []               [get list watch]
    workspaces.admin.gloo.solo.io                     []                                    []               [get list watch]
    workspacesettings.admin.gloo.solo.io              []                                    []               [get list watch]
    certificaterequests.admin.gloo.solo.io            []                                    []               [get list watch]

  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 Solo Enterprise for Istio admin resources in the gloo-mesh namespace.
      • The third request fails because the service account cannot list Solo Enterprise for Istio internal resources such as DiscoveredGateways.

Cleanup

You can optionally remove the resources that you set up as part of this guide.
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