Configure RBAC in GKE using Google Workspace Groups

Google Kubernetes Engine (GKE) is one of the most widely used managed Kubernetes engines today. It has rich feature sets and offers many automated capabilities. As per a report by Aqua Security, 90% of organizations running Kubernetes on Google Cloud rely on GKE to manage their environments. Provisioning of GKE clusters can be simple and fast with the help of an easy-to-use UI or a cloud shell/SDK.

However, implementing authentication and authorization to clusters and various associated resources can get challenging. Especially when giving access to developers, SREs/DevOps Engineers, Support Engineers & other team members. In this blog post, we are going to talk about the effective implementation of RBAC (Role Based Access Control) in the GKE cluster using the Google Workspace Groups. A similar strategy can also be applied to other managed Kubernetes services via respective IAM and Kubernetes integrations by those providers.

Why RBAC for cluster access?

Excessive privileges in a system is a security threat to organizations, and having an effective RBAC policy is one of the primary steps we can take to mitigate this risk. Here are a few more reasons to have an RBAC strategy for cluster access:

• More granular security requirements.
• Least privileged.
• Effective Authorization.
• RBAC is native to the Kubernetes ecosystem, but not the Cloud IAM.

RBAC Matrix Considered

For this use case, we could be creating user groups with different permissions. Each of the following groups can represent personas like cluster admins having admin access to the cluster, SREs responsible for a particular project/tenant (namespace) having admin access to that namespace, developers responsible for a particular project (namespace) with edit access to that namespace, and so on.

We will apply the access control mechanisms to these groups and see how it works. Below is the hierarchical Google group representation along with a role based access control list with permission set. If your organization already has Google groups per team or per business unit, you can reuse those or add those to the appropriate groups from the following table.

Why Google Workspace Groups for RBAC implementation?

• Users and groups are maintained by your Google Workspace administrators who are completely outside of Kubernetes or Cloud console. Hence your cluster administrators do not need detailed information about your users.
• Another benefit is integration with your existing user account management practices, such as revoking access when someone leaves your organization.
• Authentication happens using Google accounts.

How can we implement it for our clusters?

In order to implement RBAC to our clusters along with the permissions, below are the steps that you need to follow:

1. Create a Google workspace group called gke-security-groups@yourdomain.com. It is important to note that you cannot provide any other name for this.

2. Add gke-security-groups@yourdomain.com in the Cloud IAM user with the role Kubernetes Engine Cluster Viewer.

Note: The GCP IAM users (Google groups or individuals) should not have IAM role other than Kubernetes Engine Cluster Viewer or Kubernetes Engine Cluster Admin. These two roles don’t grant access to any Kubernetes workloads, and allow us to manage the access via Kubernetes RBAC. Other predefined IAM roles like Editor, Kubernetes Engine Admin etc. can inherently grant access to Kubernetes resources/workloads. Take a look at this article about Google Kubernetes Engine IAM Roles to understand it.

3. Update or Create a GKE cluster by adding gke-security-groups@yourdomain.com as the security group.

4. Create cluster-scoped Google workspace groups. clustername-gke-admins@yourdomain.com clustername-gke-editors@yourdomain.com clustername-gke-readonly@yourdomain.com

Note: This is mainly focussed for cluster administrators or owners

5. Create namespace-scoped Google workspace groups. clustername-ns-name-gke-admins@yourdomain.com clustername-ns-name-gke-editors@yourdomain.com clustername-ns-name-gke-editors@yourdomain.com

Note: This is mainly focused on tenant owners or developers/consumers of a namespace in a cluster.

6. Update the cluster-admin ClusterRolebinding with the cluster-scoped admin group.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: clustername-gke-admins@yourdomain.com

7. Create the following respective ClusterRoles and ClusterRolebindings for read write and read-only groups as follows:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-rw
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - 'get'
  - 'watch'
  - 'list'
  - 'create'
  - 'update'
  - 'patch'
- nonResourceURLs:
  - '*'
  verbs:
  - 'get'
  - 'watch'
  - 'list'
  - 'create'
  - 'update'
  - 'patch'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-rw
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-rw
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: clustername-gke-editors@yourdomain.com
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-ro
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - 'get'
  - 'watch'
  - 'list'
- nonResourceURLs:
  - '*'
  verbs:
  - 'get'
  - 'watch'
  - 'list'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-ro
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-ro
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: clustername-gke-readonly@yourdomain.com

8. Make sure the user is added in the respective Google workspace group for access.

9. Access the cluster using gcloud login

gcloud auth login
gcloud config set project YourGcloudProjectName
gcloud container clusters get-credentials clustername --zone=zone

10. Use the kubectl command to access the cluster resources.

11. Check the permission using kubectl auth can-i commands. Based on the way you assign users to roles and provide permissions, the access could vary. Using the auth can-i command, you can validate if the permissions and groups are working as expected. Example:

$ kubectl auth can-i patch secrets -n cart-web
yes

Conclusion

As more and more applications are containerized, organizations are turning to Kubernetes to manage them. Services like Google Kubernetes Engine not only provide simpler ways to manage your clusters, but also have good security mechanisms in place. Implementing RBAC and controlling access to your users becomes relatively easy as we just saw. If you are looking to implement an effective RBAC mechanism in place, reach out to InfraCloud for any queries.

Looking for help with Kubernetes adoption or Day 2 operations? do check out how we’re helping startups & enterprises with our Kubernetes consulting services and capabilities.

References

• Which Kubernetes Management Platform is Right for You?
• Configure role-based access control
• Create IAM policies