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.
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:
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.
|Security Group Name||Scope||Access Level|
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
firstname.lastname@example.org. It is important to note that you cannot provide any other name for this.
email@example.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.
4. Create cluster-scoped Google workspace groups.
Note: This is mainly focussed for cluster administrators or owners
5. Create namespace-scoped Google workspace groups.
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: firstname.lastname@example.org
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: email@example.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: firstname.lastname@example.org
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
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.