Create a `Role` manifest in the target namespace listing only the required `apiGroups`, `resources`, and `verbs`
Avoid using wildcard `*` for verbs or resources; enumerate only what is needed (e.g., `get`, `list`, `watch` for read-only)
Create a `RoleBinding` referencing the Role and specifying the `subjects` (ServiceAccount, User, or Group)
Apply both manifests and verify with `kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<ns>:<sa> -n <ns>`
For cross-namespace access, use a `ClusterRole` bound with a namespace-scoped `RoleBinding` rather than creating duplicate roles
Known gotchas
A `RoleBinding` referencing a `ClusterRole` grants the ClusterRole's permissions only within the binding's namespace — this is intentional and often misunderstood as a ClusterRoleBinding
ServiceAccount tokens are long-lived by default in older Kubernetes versions; for short-lived credentials use the TokenRequest API or projected service account token volumes
Escalation prevention: a user cannot grant permissions they do not themselves hold via RBAC; attempting this is rejected by the API server unless the user has the `escalate` verb
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp