This page shows you how to set up Google Groups to work with Kubernetes role-based access control (RBAC) in your Google Kubernetes Engine (GKE) clusters.
Overview
Google Groups for RBAC lets you assign RBAC permissions to members of Google Groups in Google Workspace. Your Google Workspace administrators maintain the users and groups completely outside of GKE or the Google Cloud console. Your cluster administrators therefore won't need detailed information about users.
Using Google Groups for RBAC also lets you integrate with your existing user account management practices, such as revoking access when someone leaves your organization.
To use Google Groups for RBAC, complete the following tasks:
- Meet the requirements.
- Set up your Google Groups.
- Enable Google Groups for RBAC on a cluster.
- Define and assign RBAC permissions to the Google Groups.
Requirements
To use Google Groups for RBAC, you must have access to Google Workspace or any edition of Cloud Identity.
When creating groups and adding users as members, ensure that you know the Google Groups limits.
Limitation
- GKE supports users with membership in up to 2000 groups under the security group, including nested memberships, with Google Groups for RBAC.
Set up your Google Groups
The following steps show you how to set up a group in Google Groups that works with RBAC:
Create a group in your domain named
gke-security-groups
. Thegke-security-groups
name is required. Make sure the group has the View Members permission selected for Group Members. For details, see Set permissions for managing members and content.Create groups, if they do not already exist, that represent sets of users who should have different permissions on your clusters, such as developers and cluster administrators. Each group must have the View members permission for Group members.
Add your groups as nested groups to the
gke-security-groups
group. Don't add individual users as members ofgke-security-groups
.
For more information on managing Google Groups, refer to the Google Groups Help Center.
To check whether a specific user can perform an action on a cluster resource,
GKE checks if the user is a member of a group with access and if
that group is nested in the
gke-security-groups
group.
Information about Google Groups membership is cached for a short time. It might take a few minutes for changes in group memberships to propagate to all your clusters. In addition to latency from group changes, standard caching of user credentials on the cluster is about one hour.
Enable Google Groups for RBAC on clusters
You can enable Google Groups for RBAC on new and existing GKE Standard and Autopilot clusters using the Google Cloud CLI or the Google Cloud console.
Create a new cluster
gcloud
Standard
To create a new Standard cluster and enable Google Groups for RBAC, run the following command:
gcloud container clusters create CLUSTER_NAME \
--region=COMPUTE_REGION \
--security-group="gke-security-groups@DOMAIN"
Replace the following:
CLUSTER_NAME
: the name of the new cluster.COMPUTE_REGION
: the Compute Engine region for the new cluster. For zonal clusters, use--zone=COMPUTE_ZONE
.DOMAIN
: the domain name of thegke-security-groups
group you created.
Autopilot
To create a new Autopilot cluster and enable Google Groups for RBAC, run the following command:
gcloud container clusters create-auto CLUSTER_NAME \
--region=COMPUTE_REGION \
--security-group="gke-security-groups@DOMAIN"
Console
To create a new cluster and enable the Google Groups for RBAC feature, perform the following steps:
Go to the Google Kubernetes Engine page in Google Cloud console.
Click add_box Create.
Click Configure for the cluster mode that you want to use.
For Autopilot clusters, expand the Advanced Options section to locate the Security options.
For Standard clusters, in the Cluster section, click Security.
Select the Enable Google Groups for RBAC checkbox.
Fill in Security Group with
gke-security-groups@DOMAIN
.Click Create.
Update an existing cluster
gcloud
To update an existing cluster to enable Google Groups for RBAC, run the following command:
gcloud container clusters update CLUSTER_NAME \
--region=COMPUTE_REGION \
--security-group="gke-security-groups@DOMAIN"
Replace the following:
CLUSTER_NAME
: the name of the cluster.COMPUTE_REGION
: the Compute Engine region of cluster. For zonal clusters, use--zone=COMPUTE_ZONE
.DOMAIN
: the domain name of thegke-security-groups
group you created.
Console
To update an existing cluster to enable Google Groups for RBAC, perform the following steps:
Go to the Google Kubernetes Engine page in Google Cloud console.
Click the name of the cluster that you want to update.
On the Details tab, locate the Security section.
For the Google Groups for RBAC field, click edit Edit Google Groups for RBAC.
Select the Enable Google Groups for RBAC checkbox.
Fill in Security Group with
gke-security-groups@DOMAIN
.Click Save changes.
Define and assign permissions
After creating and configuring Google Groups for RBAC, use roles and role bindings
to define RBAC permissions and assign those permissions to Google Groups
that are members of the gke-security-groups
group. For instructions, refer to
Define and assign permissions.
Verify Google Groups for RBAC configuration
The following sections show you how to verify that your Google Groups for RBAC configuration was successful, using either the gcloud CLI or the Google Cloud console.
Verify using the gcloud CLI
Run a kubectl can-i
command to check whether you can perform a specific action
against a specific Kubernetes resource. You can use this method to automate
testing RBAC access as part of your CI/CD workflow.For example, the following
command tests for get
access to pods
resources in the dev
namespace:
kubectl auth can-i get pods \
--namespace=dev \
--as=USER \
--as-group=GROUP
Replace the following:
USER
: the name of the user to impersonate, such asgke-user@example.com
. The specified user must be a member of the group for which you're testing access.GROUP
: the name of the group to impersonate, such asgke-dev-users@example.com
.
If USER
has access, the output is yes
. If
not, the output is no
.
Verify using the Google Cloud console
You can also verify RBAC access by running a kubectl command against your cluster and checking your logs.
Before you begin
Before you begin, ensure the following:
- You have not interacted with the cluster you want to test (for example, you
haven't run any
kubectl
commands) for at least one hour. Authentication is cached for one hour. Letting the cached credentials expire lets you make sure that the request gets logged when it happens. - You are a member of at least one of the groups that are members of the
gke-security-groups
group, which ensures that some Google Groups information is logged.
Enable logs and run a test command
Enable data access logging for your Google Cloud project. To enable the logging:
Go to the Audit Logs page in Google Cloud console.
In the table, select Kubernetes Engine API.
In the Log Type menu, select:
- Admin Read
- Data Read
- Data Write
Click Save.
For more information about enabling Audit Logging, see Configuring Data Access logs with the Cloud console.
Run a command using
kubectl
in the cluster, such as the following:kubectl create ns helloworld
Enter a custom query in the Logs Explorer page. To run the query:
Go to the Logs Explorer page in Google Cloud console.
Click the arrow in the Query preview box at the top of the page.
In the dropdown box that appears, specify the following query:
resource.type="k8s_cluster" resource.labels.location="CLUSTER_LOCATION" resource.labels.cluster_name="CLUSTER_NAME" protoPayload.resourceName="authorization.k8s.io/v1beta1/subjectaccessreviews" protoPayload.response.spec.user="EMAIL_ADDRESS"
Replace the following:
CLUSTER_LOCATION
: your cluster's region or zone.CLUSTER_NAME
: the name of your cluster.EMAIL_ADDRESS
: the registered email address of your Google account.
Select Run Query. At least one result should appear. If there are no results, try increasing the time range.
Select the cluster you want to examine.
Click Expand nested fields.
The field
protoPayload.request.spec.group
contains the groups where:- The groups are members of
gke-security-group
. - You are a member of the group.
This list should match the set of groups you are a member of. If no groups are present, there might be an issue with how the groups are set up.
- The groups are members of
Optionally, restore data access logging to previous settings to avoid further charges.