Transit ops needs a Role in schedules that can update ConfigMaps but must not touch Secrets. How should the Role rules be written?
Select an answer to reveal the explanation.
Short Explanation
RBAC is an allow-list, not a denylist with exclamation points. List ConfigMaps with update and leave Secrets out of the Role entirely. If Secrets never appear in the rules, that ServiceAccount or user cannot update them in schedules.
Full Explanation
Transit ops writing a Role in schedules that may update ConfigMaps but must not touch Secrets should treat RBAC as a pure allow-list. Include update (and related verbs such as get/patch as needed) on configmaps only, and omit secrets from every rule. If Secrets never appear in the Role, that subject cannot update them in schedules—like listing only schedule binders on a desk inventory and never mentioning the vault. Granting verbs on resources and trusting namespace isolation alone still authorizes Secrets inside that namespace, violating the requirement. Classic RBAC has no NotIn label selector deny for “allow secrets update but deny configmaps” patterns stated that way, and the distractor reverses the desired allow/deny anyway. Putting both resources in one rule with resourceNames: ["!secret*"] invents a denylist glob that Kubernetes RBAC does not implement; resourceNames are explicit allow-lists of names, not shell-style negations. Exam caveat: absence from rules is how you deny in RBAC; there is no general deny rule syntax for this separation. Operational check: apply the Role with only configmaps, bind the subject, confirm update on a ConfigMap succeeds and update on a Secret in schedules is forbidden via auth can-i and a dry-run apply.