How to Enable GKE Cluster Automation with Britive's Just-in-Time (JIT) Access

This is the second entry of a series that covers how Britive secures Just-In-Time (JIT) access in various Kubernetes platforms.

Britive empowers development and platform engineering teams with a modern unified access model so they can easily gain access with the proper permissions to execute their work in multi-cloud environments. As an extension of cloud service providers' (CSPs) identity and access management (IAM) capabilities, Britive’s cloud-native platform automates multi-cloud privilege identity management across cloud infrastructure, applications, and data.

A previous post of this blog series showed how developers can leverage Britive to achieve JIT access into AWS EKS clusters. This blog covers how to use Britive for JIT access within Google Kubernetes Engine (GKE) Clusters. In GKE, IAM and Kubernetes Role Based Access Control (RBAC) are integrated to authorize users to perform actions if they have sufficient permissions according to either tool. This is an important part of bootstrapping a GKE cluster since by default Google Cloud users do not have any Kubernetes RBAC RoleBindings.

Pre-Requisite

Google Groups for RBAC lets you assign RBAC permissions to members of Google Groups in Google Workspace. Here are some pre-requisite steps to follow before you are ready to create and assign Kubernetes roles to your users and service identities.

• 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.
• You will need to enable Google Groups for RBAC on new and existing GKE Standard and Autopilot clusters using the Google Cloud CLI or the Google Cloud console.
• Moving forward every new group you create to grant access to GKE will be added as nested groups to the gke-security-groups group. We would also use these groups in Britive to grant JIT access via Britive Profiles.

• Britive Profiles are configured to grant Google Groups. Britive profiles can also be configured to require approvals amongst other access control policies.
• Google Group is created and added as a nested group to gke-security-groups group. The name of this group matches the RoleBinding in Kubernetes.
• Kubernetes Role defines group permissions that can be granted to entities such as users and groups. RoleBindings allows us to bind users or groups to Kubernetes Roles.

JIT access configuration example

In this use case, we’ll mimic the role of a namespace auditor. An app-auditor role allows users to carry out GET, WATCH, and LIST actions on most resources within a namespace. This permission will not allow you to create or update any resources. We’ll be creating a test namespace, role, and role binding within our GKE Cluster.

GCP Configurations

As a Cluster Admin create a new namespace:

Now let's create a Role definition within a YAML file:

Now let's create this role within our cluster:

Next we will create a RoleBinding to bind this role to a group. Do note that users and groups in Kubernetes are not persistent entities and hence it is important that the group name gke-app1-auditor on Binding matches the name of the group we will create in the following step within the Google directory.

RoleBinding definition:

Alternatively, you may also store the Role and RoleBinding definition in one YAML file and run the kubectl apply only once.

Finally, on Google Directory create a group named gke-app1-auditor@YOURDOMAIN and add it to the gke-security-groups as a nested group.

You may assign the Google group to multiple Roles within GKE or choose to maintain 1-to-1 mapping between these entities.

Britive configuration

Now we can bring the newly created Group into Britive by running an environment scan after logging into Britive as an application or tenant admin. The group will be available on the Data tab on the application once the scan is complete:

Create a profile with this group and assign it to users or tags. Remember to add the default cluster Get and List role to the profile as well. The group screenshots below show the profile configuration:

This concludes the admin setup. You can also use Britive APIs or the Terraform provider to complete these steps.

User Experience

We’ll use PyBritive, our command line interface, and some of its powerful end-user capabilities to demonstrate the configured use case. The profile GKE App1 Auditor will allow us to check out the corresponding profiles from Britive and perform necessary actions within our GKE cluster.

Check out Britive profile. The output of this command is a gcloud auth command with ephemeral GCP service identity credentials for the user. The service identity is created JIT for the user and is granted GCP roles and Groups contained within the profile:

Let’s run the gcloud auth command to log in to GCP:

Now let's run the gcloud container to set the appropriate kubectl configuration for our session:

Next, we will run a few kubectl commands to verify our access and also demonstrate appropriate access levels:

As the assigned role is confined to a specific namespace “app1” we correctly received a “Forbidden” error when running a cluster command.

Finally, let’s run a few kubectl auth can-i to verify the correct access level and pybritive checkin to clean up our access session:

Conclusion

As this example shows, implementing JIT access in your GCP GKE clusters with varying levels of permissions is straightforward with Britive. Our unique command line interface coupled with our management console empowers developers to quickly configure and provide the right level of access for human counterparts who in turn can be more productive. Administrative functions can also be easily automated with Britive.

Learn more about Britive’s unique approach to enabling rapid access to cloud infrastructure, data, applications, and securing Kubernetes access, request a demo today.