The solution adheres to the principle of least privilege by restricting permissions to the minimum required. The first step modifies the existing Role to grant only get access to pods. The second command imperatively creates a new Role, test-role-2, granting only update permissions on statefulsets within the database namespace. The final command creates a RoleBinding to associate this new, specific Role with the test-sa ServiceAccount. This ensures the ServiceAccount has precisely the permissions needed for its tasks without being over-privileged, which is a core Kubernetes security practice.

1. Kubernetes Official Documentation

"Using RBAC Authorization". This document details the use of Roles

RoleBindings

and ServiceAccounts to manage permissions within a cluster. The examples provided illustrate the structure of the YAML manifests edited and created in the solution. (See sections: "Role and ClusterRole" and "RoleBinding and ClusterRoleBinding").

2. Kubernetes Official Documentation

"kubectl Cheat Sheet". The commands kubectl edit

kubectl create role

and kubectl create rolebinding are documented here as the standard imperative methods for managing RBAC resources.

3. Saltzer

J. H.

& Schroeder

M. D. (1975). "The protection of information in computer systems". Communications of the ACM

18(7)

38-41. This foundational paper introduces the principle of least privilege

stating that every program and every user of the system should operate using the least set of privileges necessary to complete the job (Section: "Principles of Design"

page 9). The tasks in the question are a direct application of this principle. DOI: https://doi.org/10.1145/361011.361062