K8s – Question10

Use context: kubectl config use-context k8s-c1-H

Create a new ServiceAccount processor in Namespace project-hamster. Create a Role and RoleBinding, both named processor as well. These should allow the new SA to only create Secrets and ConfigMaps in that Namespace.

Understanding and Setting Up Kubernetes RBAC with Roles and RoleBindings

In Kubernetes, Role-Based Access Control (RBAC) is a method of regulating access to resources based on the roles of individual users or service accounts. In this guide, we’ll walk through the key concepts of RBAC and demonstrate how to create and bind roles to service accounts.

Understanding RBAC Resources

RBAC in Kubernetes is built around four key resources:

  • Role: Defines a set of permissions that are available within a specific Namespace.
  • ClusterRole: Defines a set of permissions that are available cluster-wide.
  • RoleBinding: Binds a Role to a user or service account within a specific Namespace.
  • ClusterRoleBinding: Binds a ClusterRole to a user or service account cluster-wide.

There are three valid RBAC combinations:

  • Role + RoleBinding: Permissions are available and applied within a single Namespace.
  • ClusterRole + ClusterRoleBinding: Permissions are available and applied cluster-wide.
  • ClusterRole + RoleBinding: Permissions are available cluster-wide but applied within a single Namespace.

Note that the combination of Role + ClusterRoleBinding is not possible, as Roles are Namespace-scoped and cannot be applied cluster-wide.

Step 1: Create the ServiceAccount

To start, we’ll create a ServiceAccount named processor in the project-hamster Namespace:

This command will create a ServiceAccount that we will later bind to a Role.

Step 2: Create the Role

Next, we create a Role named processor in the project-hamster Namespace with permissions to create secrets and configmaps:

The command above generates a Role with the following YAML configuration:

Step 3: Bind the Role to the ServiceAccount

Now, we’ll bind the processor Role to the processor ServiceAccount using a RoleBinding:

This creates a RoleBinding with the following configuration:

Step 4: Test the RBAC Setup

To test our RBAC setup, we can use the kubectl auth can-i command. This command checks if a specific action is allowed for a user or service account. Let’s run a few checks for the processor ServiceAccount:

As expected, the processor ServiceAccount can create secrets and configmaps but cannot create pods, delete secrets, or get configmaps because the Role we defined only allows the creation of secrets and configmaps.

Conclusion

In this guide, we’ve successfully created an RBAC setup in Kubernetes. We’ve defined a Role with specific permissions, bound it to a ServiceAccount, and verified the permissions using the kubectl auth can-i command. Understanding and configuring RBAC is crucial for maintaining secure and well-organized Kubernetes environments.

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *