kubectl auth reconcile creates or updates RBAC objects from a manifest file, and with the right flags it also removes permissions and subjects that are not in the file. That makes Git the source of truth for access, as long as you run a dry run first and understand what the removal flags do.
What the command does
The RBAC reference describes it as creating or updating rbac.authorization.k8s.io/v1 objects from a manifest. Missing objects are created, and the containing namespace is created for namespaced objects if required. Existing roles gain the permissions in the input objects, and existing bindings gain the subjects, unless you remove extras with flags.
It also handles deleting and recreating binding objects when needed to change the role they refer to. That matters because a binding's role reference cannot simply be edited in place.
The three forms
kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client
kubectl auth reconcile -f my-rbac-rules.yaml
kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions
Run the first one, read the output, then the second. The third is the strict mode.
Why the strict mode matters
By default, reconcile only adds. If someone had quietly added a rule to a role, or a subject to a binding, reconcile keeps it. With the remove flags, anything not in your manifest is taken out of the objects it manages. That is how you undo drift.
The catch: it can remove access that something legitimate depends on. Roll out strict mode in a test cluster, or limit the manifest to a namespace first.
A workable workflow
- Keep Roles, ClusterRoles and bindings in a repository, in small files by team.
- Require pull request review for changes, with a note for any ClusterRoleBinding.
- Run the dry run in CI and attach the output to the pull request.
- Apply from a pipeline identity, not from laptops.
- Run strict mode on a schedule against the namespaces you manage, so drift is corrected.
Mind the built-in roles
The good practices page tells you not to change rights granted to system: accounts. Keep manifests for those out of strict mode, and do not copy the default ClusterRoles into your repository unless you mean to manage them.
Guard the pipeline
The identity that runs reconcile needs the bind or escalate verbs or the permissions it grants. That makes it a powerful credential. Scope it, keep its token short-lived and read our post on escalate, bind and impersonate.
Safeguard's policies and gates fit the pull request step: they can check RBAC manifests for wildcards and cluster-wide bindings before merge. The reconcile itself is a kubectl feature that Safeguard does not replace.
Rolling back
Because the manifests live in Git, a rollback is a revert and a reapply. Keep the previous strict run output in the pull request so you can see what was removed. If removal broke something, restore the permission by reverting the change, then add it back deliberately with a narrower rule.
Quick check
Does kubectl auth reconcile remove permissions by default?
No. By default existing roles gain permissions and bindings gain subjects. Removal requires the remove flags.
Sources
Last reviewed: 19 October 2026.
