RBAC¶

Once you’re past the “how to get started with GKE (Google Kubernetes Engine)” tutorials, you will probably realise it’s time to get a bit more serious about security in Kubernetes. When you set up your cluster, you are a cluster admin and own the key to the kingdom but eventually this ends with additional teams who needs access your GKE.

Using RBAC, Role Based Access Control, you have the power to grant specific roles (either system roles or self-defined roles) to specific people, groups or service accounts, limiting their access to only the access they need.

The main idea is to adopt pattern of least privileged access rights. This strategy demands you only give the access rights a user needs to fulfil his task, not a single permission more. For GKE, this might be a bit tricky to understand. There is Google Cloud Platform IAM, and then you have Kubernetes Roles.

GCP IAM defines what actions you are allowed to take on GCP (for example create Cloud Storage Buckets, deploy an App Engine app). Kubernetes Roles define permissions you have within a single cluster. Some GCP IAM roles actually propagate down to the GKE clusters running in that project. For example, the GCP IAM role Kubernetes Engine Developerwill give edit access to every cluster in the project this IAM role is granted on. That’s of course way too broad.

Because Kubernetes itself does not have the concept of users, GKE will rely on GCP IAM permissions to Authenticate users (who are you?). However, you should rely as much as possible on a Kubernetes Role for Authorization(what are you allowed to do?). Therefore, we will grant minimal roles on the GCP IAM side that can be used to identify yourself to a cluster. Then the GKE cluster itself will decide whatever you are allowed to do, based on a Kubernetes Role.

Google Cloud Platform IAM¶

GCP provides a predefined set of roles for GKE.  Kubernetes Engine Viewer Role provides access to get and list GKE clusters. It's is minimum required permissions to get cluster creds and to authenticate into cluster without getting access to cluster resources.

Note

It could be even more restricted with creation of custom Role, however it's not required. Below is example of minimum set of permission for custom Role.

• container.apiServices.get
• container.apiServices.list
• container.clusters.get
• container.clusters.getCredentials

Group membership over individual access¶

According to best practise we should always rely on group membership for access, rather than granting individual users specific access.

According to TDD we should create groups on Organization level (digitalturbine.com). Below offerwall-developer-sandbox groupwas created to keep users who should have readonly permissions to the cluster in Sandbox Fyber folder.

This group is mapped with Kubernetes Engine Viewer Role described above. All projects that are in Fyber folder will inherit same permissions.

Above GCP IAM configuration will give Authenticate permission to all users in offerwall-developer-sandbox group.

Warning

IMPORTANT

According to documentation for GKE, there’s a bit of a special setup needed. For Google Kubernetes Engine to respect group membership, you have that group to be a member of a dedicated group called gke-security-groups@[your-domain], as explained here.

Role Based Access Control¶

Permissions inside GKE could be managed either by ClusterRole or Role resources which contains rules that represent a set of permissions. 

A Role always sets permissions within a particular namespace; when you create a Role, you have to specify the namespace it belongs in.

ClusterRole, by contrast, is a non-namespaced resource. The resources have different names (Role and ClusterRole) because a Kubernetes object always has to be either namespaced or not namespaced; it can't be both.

If you want to define a role within a namespace, use a Role; if you want to define a role cluster-wide, use a ClusterRole.

Example how to define ClusterRole and ClusterRoleBinding with RO access to the cluster and map it to GCP IAM Group predefined previously.

---
# Source: gke-rbac/templates/clusterRole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: offerwall-sandbox-developer-ro
  labels:
    app: gke-rbac
    chart: gke-rbac
    heritage: Helm
    release: gke-rbac
rules:
- apiGroups:
    - "*"
  resources:
    - "*"
  verbs:
    - "get"
    - "list"
    - "watch"

---
# Source: gke-rbac/templates/clusterRoleBinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: clusterrolebinding-for-offerwall-sandbox-developer-ro
  labels:
    app: gke-rbac
    chart: gke-rbac
    heritage: Helm
    release: gke-rbac
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: offerwall-sandbox-developer-ro
subjects:
- kind: Group
  name: offerwall-developer-sandbox@digitalturbine.com
  apiGroup: rbac.authorization.k8s.io

We can keep our RBAC configs as a code via helm deployments, below is example of offerwall GKE RBAC:

Chart : appgrowthplatform (Gitlab)

Config: appgrowthplatform (Gitlab)

Thanks to RBAC on Kubernetes, combined with Google Groups and the least privilege access rights, we can now keep our cluster in SOX compliant way.