A lot has changed since Kubernetes was first released five years ago. K8S has become a popular platform for running production workloads, and security is a major concern for doing it. Kubernetes security relies heavily on limiting user access so that they can only do what they need to accomplish. Everyone should ideally be a cluster administrator, but that is not a good or desirable approach. Let’s look at RBAC, or Role-Based Access Control, to see how we can better accomplish this.
A Google Kubernetes course has one owner: the person who created it. Therefore, your project and its resources, including Google Kubernetes Engine (GKE) resources, are not accessible to anyone by default. However, it is possible to control resource access in your project and its clusters using role-based access control in GKE (RBAC).
- Identity and Access Management (IAM)
- Kubernetes role-based access control (RBAC)
There is some functional overlap between these processes, although they target different resources.
The following summarizes everything that you need to understand:
A built-in RBAC feature in Kubernetes allows for granular access to Kubernetes cluster items. ClusterRole and Role objects provide a way to manage access rights. For example, users of Kubernetes, Google Cloud, Google Cloud service accounts, or Google Groups can obtain Roles through RoleBinding objects. Kubernetes RBAC is ideal if you primarily utilize GKE and require fine-grained rights for every item and operation in your cluster.
Management of Google Cloud resources, such as the things found in clusters, is handled by IAM. It is the responsibility of IAM principals to grant or deny access. IAM cannot grant access to specific Kubernetes objects. Custom Resource Definitions (CRDs), for example, can be granted to a user with the right to generate CRDs. However, you can’t give this permission for a single CustomResourceDefinition (CRD), and you can’t give this permission for just one cluster or one Namespace.
When deployed at the folder level, an IAM role allows access to all clusters inside a project or all clusters within all child projects. As long as you don’t need to manage granular Kubernetes-specific permissions, IAM is an excellent option.
Integrating RBAC and IAM
We may obtain well-rounded authorization with simple methods by directing ourselves by the Principle of Least Privilege and using IAM and RBAC together. IAM roles should be used sparingly because they allow access to all clusters in a GCP project. The “Kubernetes Engine Developer” role grants edit access to all namespaces, including Kube-system, allowing anybody with this IAM role to modify fundamental system components. Of course, for a user to obtain credentials for accessing a cluster, we must grant them at least some primary access via IAM. RBAC does not work on GKE until some IAM is granted access to the cluster.
As a result, granting read-only access through the “Kubernetes Engine Viewer” IAM role is generally recommended. Granular RBAC configuration can be used to allow write and admin access to certain namespaces, extending this level of access. In GKE, IAM serves as a foundation for authorization, with RBAC serving as the structure. When you grant individual users edit or admin responsibilities in your cluster at a namespace level, you’re enhancing the read-only access you’ve already given to those users using IAM. Also, read our other blogs
