Q: 4
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 permissive permissions. Complete the
following tasks to reduce the set of permissions.
Task:
Given an existing Pod named web-pod running in the namespace database.
1. Edit the existing Role bound to the Pod's ServiceAccount test-sa to only allow performing get
operations, only on resources of type Pods.
2. Create a new Role named test-role-2 in the namespace database, which only allows
performing update operations, only on resources of type statuefulsets.
3. Create a new RoleBinding named test-role-2-bind binding the newly created Role to the Pod's
ServiceAccount.
Note: Don't delete the existing RoleBinding.
Your Answer
Discussion
Use the official docs and some hands-on labs for this, seen a similar task in practice sets.
Reviewing the official Kubernetes documentation and practicing kubectl role editing in a hands-on lab will make this type of question a breeze. Similar scenarios show up a lot, so working through sample RBAC YAML examples can really reinforce the concepts. Pretty sure that's the most efficient way to prep, but open to other resource tips.
Yep, this matches what I've seen on practice exams. It's all about least privilege here: edit the current Role so test-sa gets only get on pods, then create a new Role for update on statefulsets and bind it with a RoleBinding. Simple RBAC adjustment, just like CIS hardening guides suggest. Anyone else get this format on their CKS exam?
Yeah, saw a similar question on a practice exam. Edit the Role for pods get, create test-role-2 for statefulsets update, bind it.
Saw something like this in practice labs, key is trimming the Role to just get on pods, then new Role and RoleBinding for statefulsets update only.
Before editing the Role, do you check which roles are actually bound to test-sa first? I feel like if there’s another RoleBinding attached, you might miss over-permissive rules elsewhere. Not sure if that’s needed here though.
Nicely focused question, covers classic RBAC adjustment. For tweaks like this I always refer back to the official Kubernetes docs and do a quick practicelab run-through to make sure my edit role syntax and resource names are correct. Least privilege is the key here so sticking to only 'get' on pods and 'update' on statefulsets makes sense. If anyone disagrees, let me know.
Definitely edit the existing Role to limit it to pods get, don't delete since that could mess up current bindings. Then create test-role-2 for statefulsets update and a new RoleBinding as asked. Pretty sure that's the right workflow for least privilege, correct me if I'm missing anything.
Edit the Role (not delete), then add the new Role and RoleBinding for statefulsets update only.
Makes sense to lock down the verbs for pods to just get, and create a new Role for update on statefulsets. So it’d be kubectl edit role, then create the new Role and RoleBinding. That lines up with least privilege in k8s security.
Be respectful. No spam.
