You can switch the cluster/configuration context using the following command: [desk@cli] $ kubectl config use-context prod-account Context: A Role bound to a Pod's ServiceAccount grants overly…

Question

Exhibits

Explanation

Refactor Kubernetes RBAC permissions by editing an existing Role to be less permissive and creating a new Role and RoleBinding to grant specific update permissions for statefulsets to a ServiceAccount.

Approach. The correct approach involves executing a series of kubectl commands in the CLI, ensuring to use the specific object names, permissions, and namespace (database) as stated in the question, rather than following the potentially misleading examples or incorrect parameters shown in the exhibit images.

1. Identify ServiceAccount: The question states the Pod's ServiceAccount is test-sa in the database namespace. This is the subject for the RoleBinding.

2. Edit the existing Role (dev-role): The task requires modifying dev-role to allow only get operations on Pods in the database namespace.

   • Interaction: Execute kubectl edit role dev-role -n database.
   • Inside the text editor (e.g., vi or nano), locate the rules section and modify it to precisely define the required permissions. Pods are a core API resource, so their apiGroups entry is an empty string "".
   • Modified rules section:

     rules:
     - apiGroups:
       - ""
       resources:
       - "pods"
       verbs:
       - "get"
     

   • Save and exit the editor.

3. Create a new Role (test-role-2): This Role needs to grant update operations on statefulsets in the database namespace.

   • Interaction: Since statefulsets belong to the apps API group, and kubectl create role --resource flag defaults to apiGroups: [""] (core API group), creating the Role directly with flags is technically incorrect. The most robust and correct method is to create a YAML manifest and apply it.
   • Create test-role-2.yaml with the following content:

     apiVersion: rbac.authorization.k8s.io/v1
     kind: Role
     metadata:
       name: test-role-2
       namespace: database
     rules:
     - apiGroups:
       - "apps" # Crucial: StatefulSets are in the 'apps' API group
       resources:
       - "statefulsets"
       verbs:
       - "update"
     

   • Execute: kubectl apply -f test-role-2.yaml

4. Create a new RoleBinding (test-role-2-bind): This binding connects the test-role-2 Role to the test-sa ServiceAccount in the database namespace.

   • Interaction: Execute kubectl create rolebinding test-role-2-bind --role=test-role-2 --serviceaccount=database:test-sa -n database.

Common mistakes.

• common_mistake. Common mistakes include:

• Incorrect Namespace: Using security as the namespace for any command (e.g., kubectl edit role dev-role -n security, kubectl create role test-role-2 -n security, etc.) instead of database, as explicitly specified in the question. This would result in the RBAC objects being created in the wrong namespace and not applying to the target Pod/ServiceAccount.
• Incorrect ServiceAccount Name: Referencing sa-dev-1 (from the exhibit) instead of test-sa (from the task) when creating the RoleBinding. The permissions would be bound to the wrong identity.
• Incorrect Permissions for dev-role: Editing dev-role to have permissions other than get on pods (e.g., keeping * for resources/verbs, or applying watch on services as shown in the exhibit's demonstration) would fail to meet the task's requirement to reduce overly permissive permissions to a specific get operation on pods.
• Incorrect API Group for test-role-2 (StatefulSets): If the new test-role-2 is created using kubectl create role --resource=statefulsets without explicitly defining the apiGroups: ['apps'] via a manifest, the command would default apiGroups to [''] (core API group). This would make the Role ineffective for statefulsets, as they reside in the apps API group.
• Deleting Existing RoleBinding: The note explicitly states 'Don't delete the existing RoleBinding'. Any command or action that would remove the original binding would be incorrect.
• Missing or Incorrect RoleBinding: Failing to create test-role-2-bind, or binding test-role-2 to an incorrect ServiceAccount or Role, would mean the new update permissions are not effectively granted.

Concept tested. The core concepts tested are Kubernetes Role-Based Access Control (RBAC), including the definition and management of Role and RoleBinding resources. Specifically, it assesses the ability to:

• Understand and define permissions using apiGroups, resources, and verbs.
• Correctly identify the appropriate API group for specific Kubernetes resources (e.g., pods in "" for core, statefulsets in apps).
• Associate Roles with ServiceAccounts using RoleBinding.
• Modify existing RBAC resources (kubectl edit).
• Create new RBAC resources (kubectl create role, kubectl create rolebinding).
• Apply the principle of least privilege by restricting overly permissive permissions.
• Manage RBAC objects within specific namespaces (-n flag).
• Understand the relationship between Pods and ServiceAccounts for authorization within a cluster.

No community discussion yet for this question.