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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1713199436125/10c825a8-e89a-4c35-a630-46be48cf004f.png align="center")

### Prerequisite:

1) Google Kubernetes cluster

### Solution:

To begin, let's create an IAM user:

Navigate to your Google Cloud IAM console.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1713199856135/612e9e7d-2902-464f-88ef-696c831fb588.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1713199942722/49396d3a-3754-40e9-a630-2466d64b6cd3.png align="center")

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\]](https://console.cloud.google.com/invitation?project=[your-project-id]&account=[the-account-email-invited]&memberEmail=[the-account-email-invited])

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1713200598085/68711349-170d-40e3-be05-981c043a924c.png align="center")

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.

```plaintext
gcloud auth login 
```

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

To see you login in configration. Run following command.

```plaintext
gcloud config list account 
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1713201012605/1918566a-3fea-466f-9230-5e5fba6893ee.jpeg align="center")

To see authorized cluster.

```plaintext
gloud container clusters list
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1713201362435/d490ff01-a43d-40c5-a3ac-39b501584e5f.jpeg align="center")

To connect with GKE cluster.

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1713201800740/479c4593-6fc1-47a0-a01f-6759576a262b.jpeg align="center")

Let's see what user can access in cluster.

```plaintext
kubectl get po
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1713201941218/240ec83b-1aac-4164-b2cb-24227f3802c6.png align="center")

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)

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

```plaintext
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 permissi[o](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)ns 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. <mark>A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide.</mark>

A RoleBinding may reference any Ro[l](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)e 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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1713202784311/a99c405b-be10-4953-9416-d6aa2b1e9fb1.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1713202921214/8f4ac720-77e0-45ae-a051-f96b037be673.jpeg align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1713203059122/d9d146bb-2741-43a0-8456-522ad8ae19f5.jpeg align="center")

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.