A municipal CI bot must create Secrets only in billing, but someone bound a ClusterRole with a ClusterRoleBinding by mistake. What should ops change first to restore least privilege?
Select an answer to reveal the explanation.
Short Explanation
The bot got a master key when it only needed the billing vault combination. Swap the ClusterRoleBinding for a RoleBinding in billing so create-secret stops spanning the whole cluster. Same verbs, tighter door.
Full Explanation
A municipal CI bot that must create Secrets only in billing was mistakenly given cluster-wide reach through a ClusterRoleBinding. The first corrective step is to replace that ClusterRoleBinding with a RoleBinding in billing, keeping either a Role defined in that namespace or a ClusterRole referenced from a namespaced RoleBinding. RoleBindings confine the granted verbs to one namespace, restoring the vault-combination model instead of a master key across every city namespace. Deleting the ServiceAccount removes the bot’s identity entirely and breaks pipelines instead of tightening scope—authentication should remain; authorization should shrink. A NetworkPolicy that drops egress toward etcd does not authorize or de-authorize Secret creation on the API server and can harm cluster health if misapplied on workers. Turning Secret create into an Ingress annotation on the billing Service confuses routing metadata with RBAC; Ingress annotations never grant create on secrets. Exam caveat: ClusterRoleBinding always grants cluster-wide; to reuse a ClusterRole’s rules in one namespace only, bind it with a RoleBinding in that namespace. Operational check: delete or replace the mistaken ClusterRoleBinding, apply the billing RoleBinding, then verify the CI ServiceAccount can create Secrets in billing and cannot create them elsewhere via kubectl auth can-i create secrets -n … as that ServiceAccount.