Grant an agent least-privilege kube-apiserver access with RBAC, including subresources

Documented steps

1. Decide the exact API group, resource, and verbs the agent needs. Core resources (pods, configmaps, services) use apiGroups: [""]; others use their group, e.g. apiGroups: ["apps"] for deployments.
2. Address subresources with 'resource/subresource' syntax in the rules. Example: resources: ["pods", "pods/log"] is required to call GET /api/v1/namespaces/{ns}/pods/{name}/log — access to 'pods' alone does NOT grant the log subresource.
3. Create a namespaced Role (apiVersion: rbac.authorization.k8s.io/v1, kind: Role) with rules listing apiGroups, resources, and verbs; use ClusterRole instead for cluster-scoped resources or cross-namespace access.
4. Narrow further with resourceNames when the agent only needs specific named objects: resourceNames: ["my-config"]. Note resourceNames only constrains verbs that address a single object (get, update, patch, delete) — it cannot restrict list or watch.
5. Bind the Role with a RoleBinding whose subjects entry is: {kind: ServiceAccount, name: <sa-name>, namespace: <sa-namespace>}, and whose roleRef is {kind: Role, name: <role-name>, apiGroup: rbac.authorization.k8s.io}.
6. Use a ClusterRoleBinding only when the permission genuinely must span all namespaces; a RoleBinding can also reference a ClusterRole to reuse a role definition while scoping it to one namespace.
7. Verify the result before relying on it: POST a SelfSubjectAccessReview (see the permission-check route) or run 'kubectl auth can-i <verb> <resource> --subresource=<sub> -n <ns>'.
8. Re-check after adding any new capability — writing via Server-Side Apply needs 'patch', and additionally 'create' if the object may not exist yet.
9. Docs: https://kubernetes.io/docs/reference/access-authn-authz/rbac/ and https://kubernetes.io/docs/reference/access-authn-authz/authorization/