When you install a Gloo product, you deploy several core and addon components, such as the management server, agent, and external auth service. For more information about the components, see Platform 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 or Clickhouse databases, 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-platform
      

    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-platform cluster role.

      Role:
        Kind:  ClusterRole
        Name:  gloo-mesh-mgmt-server-gloo-platform
    Subjects:
        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-platform-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
  • External auth service

Resources that you can restrict access to:

  • Kubernetes secrets

At a minimum, you must allow access to the following namespaces for each Gloo component:

  • gloo-mesh, or if you used a different name, the namespace that your management server, UI, and agent are deployed to.
  • The namespace where your add-on components, such as the external auth service, rate limiter, or developer portal, are deployed to. Depending on your setup, you might have all of these Gloo components together in a single namespace, which defaults to gloo-mesh, or a separate namespace.
  1. Check the Helm releases in your cluster. Depending on your installation method, you either have only a main installation release (such as gloo-platform), or a main installation and a separate add-ons release (such as gloo-agent-addons), in addition to your CRDs release.

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

    • If you have only one release for your installation, get those values. Note that your Helm release might have a different name.

        helm get values gloo-platform -n gloo-mesh -o yaml > gloo-single.yaml
      open gloo-single.yaml
        
    • If you have a separate add-ons release, get those values.

        helm get values gloo-agent-addons -n gloo-mesh -o yaml > gloo-agent-addons.yaml
      open gloo-agent-addons.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 use a different namespace, or if you maintain a separate add-ons namespace, modify 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).

    • If you have only one release for your installation, upgrade the gloo-platform release. Note that your Helm release might have a different name.

        helm upgrade -i gloo-platform gloo-platform/gloo-platform \
         --namespace gloo-mesh \
         --create-namespace \
         --values $VALUES_FILE \
         --version $GLOO_VERSION
        
    • If you have a separate add-ons release, upgrade the gloo-agent-addons release.

        helm upgrade -i gloo-agent-addons 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.