Control user access to Gloo resources
Use Kubernetes RBAC to control user access to Gloo resources in your clusters.
Before you begin
- Add the Gloo custom resource definitions (CRDs) to all of your Kubernetes clusters by following the getting started or an advanced installation guide.
- 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.
- 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.
Set up Kubernetes RBAC for Gloo resources
List the Gloo resources, their related API groups, and possible verbs.
Example output:
Optional: Get the details of an existing role or cluster role to modify, such as the default Kubernetes cluster roles
admin
,edit
, andview
.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.Create a service account in the same namespace as your role to test permissions.
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.
Check the permissions that the service account has.
Verify that the service account can get the resources.
Get and decode the token from the secret for the service account.
Save the token output of the previous step as an environment variable.
Get the cluster endpoint for API access.
Example output:
Save the cluster endpoint without the port as an environment variable.
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.
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.