Kubernetes role-based access control
1. Kubernetes role-based access control
Kubernetes Role-Based Access Control, or RBAC, is a built-in security mechanism that allows for granular control over user permissions within a Kubernetes cluster. Within GKE, RBAC works alongside IAM to strengthen security. While IAM manages access at the GKE and cluster levels, RBAC provides control over individual Kubernetes resources inside the cluster. Kubernetes RBAC can control who can do what with Kubernetes objects. Subjects, the who, are users, groups, or service accounts authorized to interact with the Kubernetes API server. Verbs, the what, define the specific actions allowed for each resource, such as creating, modifying, or viewing. And resources encompass the Kubernetes objects the subjects can access, like Pods, Deployments, or persistent volumes. Think of it as defining who gets the keys, what doors they can unlock, and what actions they can perform inside. By combining these elements, two types of RBAC API objects can be created, roles and RoleBindings. Both applied at the cluster or namespace level, roles connect API resources and verbs and RoleBindings connect roles to subjects. To use RBAC to grant users access to specific Kubernetes namespaces, you need to create roles and RoleBindings. First, you need to create the roles with proper permissions in each namespace. Then you need to create RoleBindings to bind subjects to the appropriate roles. So, how does this work in practice? Let’s explore how a manifest defines an RBAC role at the namespace level. A manifest includes fields of the apiVersion, kind, metadata, and rules, which are permissions granted by the role. Using the kind field, Role can be used to define a namespace-level role. Note that you can only define a single namespace for a role. Under the rules field, you need to define the permissions granted by the role. This includes apiGroups, which are API groups of resources. Leave this field empty for the core API group. The resources field specifies what resources the role can access, like “Pods”, and the verbs field specifies the permitted actions on those resources. Whereas RBAC Roles are defined at the namespace level, RBAC ClusterRoles are defined at the cluster level. In practice, this means defining the kind field of a manifest file with ClusterRole and leaving the metadata field blank, indicating a cluster-wide scope. Let’s explore some rule sets that specify the resources and verbs covered by a Role or ClusterRole. A resourceName is used to limit the scope to specific instances of a resource and the verbs specified as patch and update. A subresource ‘logs’ can be added to the resources list to specify access to Pod logs also. The combination of verbs get, list and watch are the standard read-only verbs. You should typically assign them as a unit, all or none. And nonResourceURLs can be used to specify get and post actions for non-resource endpoints. This form of rule is unique to ClusterRoles. After ClusterRoles are defined, RoleBindings and ClusterRoleBindings can be attached. To attach a RoleBinding, start by defining the namespace where it applies, then carefully specify the users, groups, or service accounts that will receive the permissions, paying attention to case sensitivity in their names. With RBAC in GKE, you can control access for various user types: individual Google accounts, service accounts tied to Google Cloud projects, and identities associated with your workloads through Workload Identity. All these entities are identified by their email addresses. To connect roles to users or groups, use the roleRef field within a RoleBinding. Specify both the role type–Role or ClusterRole–and its name. Remember, even ClusterRoles bound within a RoleBinding only grant permissions within the specific namespace, not the entire cluster. To identify both namespaced and non-namespaced resources, use the kubectl api-resources command, and specify --namespaced=true for namespaced resources and --namespaced=false for cluster-wide resources. Before creating Roles or ClusterRoles, you can verify the resource scope–namespace or cluster-wide–using kubectl api-resources to list "NameSpaced" resources. Typically, you should manage cluster-level resources with ClusterRoles and NameSpaced resources with Roles. For permissions spanning multiple namespaces, you'll likely need to use ClusterRoles.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.