How many acronyms or abbreviations can I fit into one title. As an organization leverages kubernetes more and more, a shared environment may become more prevalent, rather than many clusters. There are advantages to a shared environment, less clusters to manage when it may not be necessary. The first step into a shared environment is namespace isolation between services, teams, environments, etc.
GKE provides you with the necessary resources to create such isolation, but you need to properly define roles and k8s rbac roles. While GCP provides predefined GKE roles for users/groups such as GKE Admin, GKE Developer, etc, these are cluster wide roles. Meaning an user/group who has this role would have access to all the specified resources/actions across all namespaces within a cluster. While it makes sense for some user/groups to have cluster wide roles, to isolate namespaces, today we would create a custom role with a specific permission,
Why do we need this? Today, a developer, ops, anyone that needs auth or an automation tool via GCP service account to a GKE cluster, may need access to properly
get-credentials via the gcloud command. Like the predefined roles, once you are able to
get-credentials it configures your kubeconfig for
kubectl to use. However that is all they can do, once they can get access to the cluster, k8s RBAC can take over binding specific
Also today, GKE only passes down the user account / email down to the k8s instance. For a binding (
ClusterRoleBinding) subject, only
kind: User is available. So while you can assign GCP IAM roles permissions to groups, only the individual user account is passed down. We wouldn’t be able to take advantage of
The kubernetes documentation provides a good initial overview to RBAC. Some things to keep noted, for
apiGroups: [""]references the core
v1api, if you want to provide permission to other
apiGroupsyou’ll have to specify them. You can find them for your cluster with
kubectl api-versions. Such as wanting to leverage,
resources: ["deployments"]references the kubernetes resources
verbs: ["get", "create"]references the verb actions the role can perform.
RoleBinding are bound to a namespace, while
ClusterRoleBinding are bound to the cluster. For instance, you can also have a
RoleBinding at the namespace level of a
This post is based on this example.