Configure Google Groups for RBAC

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:

1. Meet the requirements.
2. Set up your Google Groups.
3. Enable Google Groups for RBAC on a cluster.
4. 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:

1. Create a group in your domain named gke-security-groups. The gke-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.

2. 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.

3. Add your groups as nested groups to the gke-security-groups group. Don't add individual users as members of gke-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 container clusters create CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --security-group="gke-security-groups@DOMAIN"

gcloud container clusters create-auto CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --security-group="gke-security-groups@DOMAIN"

Update an existing cluster

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --security-group="gke-security-groups@DOMAIN"

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 as [email protected]. 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 as [email protected].

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

1. Enable data access logging for your Google Cloud project. To enable the logging:

   1. Go to the Audit Logs page in Google Cloud console.

      Go to Audit Logs

   2. In the table, select Kubernetes Engine API.

   3. In the Log Type menu, select:

      • Admin Read
      • Data Read
      • Data Write

   4. Click Save.

   For more information about enabling Audit Logging, see Configuring Data Access logs with the Cloud console.

2. Run a command using kubectl in the cluster, such as the following:

   kubectl create ns helloworld
   

3. Enter a custom query in the Logs Explorer page. To run the query:

   1. Go to the Logs Explorer page in Google Cloud console.

      Go to Logs Explorer

   2. Click the arrow in the Query preview box at the top of the page.

   3. 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.

   4. Select Run Query. At least one result should appear. If there are no results, try increasing the time range.

   5. Select the cluster you want to examine.

   6. Click Expand nested fields.

   7. 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.

4. Optionally, restore data access logging to previous settings to avoid further charges.

What's next

• Learn more about RBAC and IAM in GKE.
• Learn how to harden your clusters.