When you install a Gloo product, you deploy several core components, such as the management server, Gloo UI, and agent. For more information about the components, see the architecture.

These components might come with a default set of permissions granted by Kubernetes RBAC cluster roles and roles. Some components that do not need Kubernetes permissions, such as Redis database, do not have Kubernetes RBAC resources. Other components, such as the management server, agent, and UI, might have several cluster roles that are used to scope certain permissions on sensitive resources such as secrets to namespaces.

Check the RBAC setup

In Kubernetes RBAC, roles and cluster roles configure a set of permissions, such as to view or modify Kubernetes objects. Role bindings and cluster role bindings bind these permissions to a subject in Kubernetes, such as a service account. For more information, see the Kubernetes docs. Most Gloo components have their own Kubernetes service accounts, roles or cluster roles, and role bindings or cluster role bindings.

To check the RBAC setup for each component, you can run the following commands. Alternatively, you can check the permissions tables for each component in Review Gloo permissions.

  1. Get the Kubernetes RBAC resources for the Gloo component that you want to check.

  2. Check the role binding or cluster role binding for the component. Make sure that the role or cluster role in the Role section and the service account in the Subjects section match the names for the Gloo component in the output from the previous step.

      kubectl describe clusterrolebinding gloo-mesh-mgmt-server-gloo-mesh

    Example output: The cluster role binding grants the gloo-mesh-mgmt-server service account access in the gloo-mesh namespace the gloo-mesh-mgmt-server-gloo-mesh cluster role.

        Kind:  ClusterRole
        Name:  gloo-mesh-mgmt-server-gloo-mesh
        Kind            Name                   Namespace
        ----            ----                   ---------
        ServiceAccount  gloo-mesh-mgmt-server  gloo-mesh
  3. Get the details of a cluster role or role. Check the PolicyRule in each role or cluster role to review specific permissions.

  4. Repeat the previous step for each component that you want to check. The following commands check all roles and cluster roles per component and pipe the output to jq to get only the PolicyRules. Alternatively, you can check the permissions tables for each component in Review Gloo permissions.

Review Gloo permissions

Review the following tables that describe the default permissions by Gloo component. For steps to check these permissions in your cluster setup, see Check default RBAC setup. For steps to modify these permission, see Restrict default permissions.

Restrict default permissions

You can restrict the permissions for select Gloo components. By default, Gloo components use Kubernetes cluster roles and cluster role bindings to get access to resources on a cluster-wide level. To restrict these permissions, configure the namespacedRbac Helm option for select Gloo components during your Gloo installation or upgrade.

  • Default behavior without namespacedRbac: Gloo creates separate cluster roles and cluster role bindings per component for the resources that can and cannot be restricted to namespaces. For resources that can be restricted by namespace, the cluster role and cluster role bindings have *-namespaced in their name.
  • With namespacedRbac: Gloo creates roles and role bindings per component for the restricted resources in the selected namespaces, such as gloo-mesh. These roles and role bindings have *-namespaced in their name, such as gloo-mesh-mgmt-server-gloo-mesh-gloo-mesh-namespaced. Gloo still creates a cluster role and cluster role binding per component for all the other resources that the component needs access to.

Gloo components that you can restrict access for:

  • Gloo management server
  • Gloo agent
  • Gloo UI

Resources that you can restrict access to:

  • Kubernetes secrets

At a minimum, you must allow access to gloo-mesh, or if you used a different name, the namespace that your management server, UI, and agent are deployed to.

  1. Check the Helm releases in your cluster.

      helm ls -A
  2. Get your current installation values.

      helm get values gloo-platform -n gloo-mesh -o yaml > gloo-single.yaml
    open gloo-single.yaml
  3. Add the following settings in the sections for each component that you want to restrict Kubernetes RBAC permissions to namespaces. Keep in mind the following points:

    • You can restrict only Kubernetes secrets.
    • You must include the namespaces that the Gloo components are deployed to, such as gloo-mesh. If your namespaces have different names, replace these values.
    • You add these values along with all the rest of the values in your Helm configuration file.
  4. Upgrade your Helm release with the namespaced RBAC restrictions. Be sure to include the Helm values file ($VALUES_FILE) that you previously created and the Gloo version of your current installation ($GLOO_VERSION).

      helm upgrade -i gloo-platform gloo-platform/gloo-platform \
      --namespace gloo-mesh \
      --create-namespace \
      --values $VALUES_FILE \
      --version $GLOO_VERSION
  5. Verify that your Gloo environment is healthy. Note that this check might take a few seconds to complete.

      meshctl check
  6. Confirm that the permissions are correct by checking the RBAC setup.