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.
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.
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]
...
Optional: Get the details of an existing role or cluster role to modify, such as the default Kubernetes cluster roles admin, edit, and view.
Get the name of the existing role that you want to modify.
kubectl get roles -A
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
Get the name of the existing cluster role that you want to modify.
kubectl get clusterroles -A
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
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 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.
kubectl auth can-i get failoverpolicies --as=system:serviceaccount:gloo-mesh:gloo-rbac-service-account -n gloo-mesh
kubectl auth can-i get workspaces --as=system:serviceaccount:gloo-mesh:gloo-rbac-service-account -n gloo-mesh
kubectl auth can-i get failoverpolicies --as=system:serviceaccount:gloo-mesh:gloo-rbac-service-account
Example output:
yes: The service account can get failover policies in the gloo-mesh namespace, as expected.
no: The service account cannot get workspaces in the gloo-mesh namespace, because the role only gives viewer permissions for Gloo policies, not admin resources.
no: The service account cannot get failover policies in the default namespace, because the role and role binding are scoped to the gloo-mesh namespace.
Resources Non-Resource URLs Resource Names Verbs
wasmdeploymentpolicies.extensions.policy.gloo.solo.io [] [] [get list watch]
externalendpoints.networking.gloo.solo.io [] [] [get list watch]
externalservices.networking.gloo.solo.io [] [] [get list watch]
routetables.networking.gloo.solo.io [] [] [get list watch]
virtualdestinations.networking.gloo.solo.io [] [] [get list watch]
virtualgateways.networking.gloo.solo.io [] [] [get list watch]
accesslogpolicies.observability.policy.gloo.solo.io [] [] [get list watch]
connectionpolicies.resilience.policy.gloo.solo.io [] [] [get list watch]
failoverpolicies.resilience.policy.gloo.solo.io [] [] [get list watch]
faultinjectionpolicies.resilience.policy.gloo.solo.io [] [] [get list watch]
outlierdetectionpolicies.resilience.policy.gloo.solo.io [] [] [get list watch]
retrytimeoutpolicies.resilience.policy.gloo.solo.io [] [] [get list watch]
accesspolicies.security.policy.gloo.solo.io [] [] [get list watch]
corspolicies.security.policy.gloo.solo.io [] [] [get list watch]
csrfpolicies.security.policy.gloo.solo.io [] [] [get list watch]
extauthpolicies.security.policy.gloo.solo.io [] [] [get list watch]
jwtpolicies.security.policy.gloo.solo.io [] [] [get list watch]
wafpolicies.security.policy.gloo.solo.io [] [] [get list watch]
headermanipulationpolicies.trafficcontrol.policy.gloo.solo.io [] [] [get list watch]
mirrorpolicies.trafficcontrol.policy.gloo.solo.io [] [] [get list watch]
proxyprotocolpolicies.trafficcontrol.policy.gloo.solo.io [] [] [get list watch]
ratelimitclientconfigs.trafficcontrol.policy.gloo.solo.io [] [] [get list watch]
ratelimitpolicies.trafficcontrol.policy.gloo.solo.io [] [] [get list watch]
transformationpolicies.trafficcontrol.policy.gloo.solo.io [] [] [get list watch]
Verify that the service account can get the resources.
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
Save the token output of the previous step as an environment variable.
export SA_TOKEN=<ey...>
Get the cluster endpoint for API access.
kubectl get endpoints | grep kubernetes
Example output:
kubernetes 34.xx.xxx.xxx:443 1d
Save the cluster endpoint without the port as an environment variable.
export CLUSTER_ENDPOINT=<34.xx.xxx.xxx>
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.