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:
kubectl create namespace app1Now let’s create a Role definition within a YAML file:
kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: app-auditor namespace: app1 rules: - apiGroups: ["*"] resources: ["*"] verbs: ["get", "watch", "list"] - apiGroups: ["batch"] resources: - jobs - cronjobs verbs: ["*"]
Now let’s create this role within our cluster:
kubectl apply -f ./app-auditor.yaml
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:
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: app-auditor-access namespace: app1 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: app-auditor subjects: - kind: Group namespace: app1 name: gke-app1-auditor@YOURDOMAIN kubectl apply -f ./app-auditor-access.yaml
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.
Security Groups setup in Google Directory
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:
Permissions carried by a profile
Basic 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:
pybritive checkout "GCP-CIS/GKE App1 Auditor" -m gcloudauth -t demo
.
gcloud auth activate-service-account palakchheda-2tiydnt39vjlkkpjw8@YOURDOMAINPROJECT --key-file /Users/palak/.britive/pybritive-gcloud-key-files/affcb5b6568f51d81a2a8.json
Let’s run the gcloud auth command to log in to GCP:
gcloud auth activate-service-account palakchheda-2tiydnt39vjlkkpjw8@YOURDOMAINPROJECT --key-file /Users/palak/.britive/pybritive-gcloud-key-files/affcb5b6568f51d81a2a8.json
Activated service account credentials for: [palakchheda-2tiydnt39vjlkkpjw8@YOURDOMAINPROJECT]
Now let’s run the gcloud container to set the appropriate kubectl configuration for our session:
gcloud container clusters get-credentials test-jit --region us-central1 --project my-first-project-310615 Fetching cluster endpoint and auth data. kubeconfig entry generated for test-jit.
Next, we will run a few kubectl commands to verify our access and also demonstrate appropriate access levels:
kubectl get namespaces Error from server (Forbidden): namespaces is forbidden: User "palakchheda-2tiydnt39vjlkkpjw8@YOURDOMAINPROJECT" cannot list resource "namespaces" in API group "" at the cluster scope: requires one of ["container.namespaces.list"] permission(s). kubectl get pods --namespace app1 No resources found in app1 namespace.
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:
kubectl auth can-i get pods -n app1 yes kubectl auth can-i get pods --all-namespaces no - requires one of ["container.pods.get"] permission(s). kubectl auth can-i get deployments -n app1 yes kubectl auth can-i get deployments -n dev no - requires one of ["container.deployments.get"] permission(s). kubectl auth can-i patch pods -n app1 no - requires one of ["container.pods.update"] permission(s). kubectl auth can-i get pods -n app1 yes pybritive checkin "GCP-CIS/GKE App1 Auditor"
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.
