Namespace-scoped RBAC for a ServiceAccount

WHAT THIS TESTS This checks that you can implement least-privilege RBAC confined to a single namespace, with the correct apiGroup wiring that trips many people up.

A GOOD ANSWER COVERS You need two objects, both namespaced to production. First, a Role in namespace production whose rules grant the create verb. Deployments live under apiGroups apps, so one rule sets apiGroups apps, resources deployments, verbs create. Services are core-group resources, so a second rule sets apiGroups with the empty string, resources services, verbs create. Second, a RoleBinding in namespace production whose roleRef points to that Role and whose subjects list the ServiceAccount with its name and namespace. Because both the Role and the RoleBinding are namespaced to production, the granted permissions cannot escape that namespace. You would typically also grant get and list so tooling can verify what it created, but strictly create is enough to satisfy the requirement.

COMMON WRONG ANSWERS Using a ClusterRole with a ClusterRoleBinding grants the permission in every namespace, violating the requirement. Putting deployments under the core group, empty apiGroups, makes the rule match nothing because deployments are in apps. Forgetting that the ServiceAccount subject needs its namespace specified.

LIKELY FOLLOW-UPS Which apiGroup various resources belong to. How a RoleBinding could reuse an existing ClusterRole but stay namespaced. How the pod consumes the ServiceAccount token.

ONE CONCRETE EXAMPLE Role deployer in production allows create on apps/deployments and core/services. RoleBinding deployer-binding in production binds it to ServiceAccount ci in namespace production. That SA can create those resources only in production and is forbidden everywhere else.