Granting Cluster Access with IAM and RBAC Simplified

Problem Statement:

In a dynamic cloud environment, restricting access to your Google Kubernetes Engine (GKE) cluster can hinder collaboration and slow down development and operations. Without proper access controls, team members may face delays in accessing resources, leading to decreased productivity and missed deadlines. Additionally, unauthorized access to critical cluster resources can result in security breaches, data leaks, or inadvertent modifications, posing significant risks to the integrity and confidentiality of your applications and infrastructure.

How can we solve:

Implementing robust authentication and authorization mechanisms such as Identity and Access Management (IAM) and Role-Based Access Control (RBAC) in GKE can mitigate these challenges. IAM allows you to manage user identities and their permissions, while RBAC enables granular control over who can perform specific actions within the cluster. By configuring IAM roles and RBAC policies effectively, you can streamline access management, enforce least privilege principles, and safeguard your GKE cluster against unauthorized access and potential security threats. This ensures that team members can collaborate seamlessly while maintaining the confidentiality, integrity, and availability of your Kubernetes workloads.

Prerequisite:

1) Google Kubernetes cluster

Solution:

To begin, let's create an IAM user:

Navigate to your Google Cloud IAM console.

Click on "Grant Access" and provide the email address of the user you wish to grant access to. Select the "Kubernetes Engine Cluster Admin" role and click "Save".

Here's the catch: If you assign any role other than "owner", Google doesn't send an invitation email.

So, to get access google project without invitation email. Provie Following URl to your User.

https://console.cloud.google.com/invitation?project=[your-project-id]&account=[the-account-email-invited]&memberEmail=[the-account-email-invited]

Let's Setup everything on user system and see what they can do on cluster.

To login to your account in cli. Run following command.

gcloud auth login

It will prompt you to login to your google cloud account.

To see you login in configration. Run following command.

gcloud config list account

To see authorized cluster.

gloud container clusters list

To connect with GKE cluster.

gcloud container clusters get-credentials $CLUSTER  --region $REGION

Let's see what user can access in cluster.

kubectl get po

So, user is authenticated but not authorized till now.

Let's do that

Let's create one role using following manifest.(You should create role and rolebinding using your admin account, Not from user account)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

For rolebinding use following manifest.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-reader-binding
  namespace: default
subjects:
- kind: User
  name: <user email id>
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

What is rolebinding and clusterbinding?

RoleBinding and ClusterRoleBinding

A role binding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide.

A RoleBinding may reference any Role in the same namespace. Alternatively, a RoleBinding can reference a ClusterRole and bind that ClusterRole to the namespace of the RoleBinding. If you want to bind a ClusterRole to all the namespaces in your cluster, you use a ClusterRoleBinding.

Now apply both configuration from Amin account.

Now Let's try to see effect of this from User account. From User account try to access pod.

Now, Let's Try to list deployment or create pod.

Woooh . We have configured our RBAC on cluster.

Wait. It not over yet. What if you don't want to give access to you project(using console) then You can also give CLI permission only by giving service account in Google IAM.

If you want to learn that please do comment i will cover that in another blog article.

Okay. That's it? Remember this is not only way to give access to your cluster. This is one of the way. In production you can use IDP(like Okta) for Authentication Or you can use client certificate for authentication.

That's it from side.