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
Kubernetes Role rules are additive allow rules. To permit ConfigMap updates without Secret access, specify configmaps (with update or the needed verb set) and do not include secrets. There is no standard RBAC deny rule or !secret resourceName pattern for this separation. Wildcard on all resources would authorize Secrets as well.