To move a cluster from ABAC to RBAC, run both authorizers in parallel, write RBAC rules for each ABAC policy, watch the logs for RBAC denials, and remove ABAC when workloads show none. A request allowed by either authorizer proceeds, so you can migrate gradually.
Why migrate
ABAC rules live in a policy file that the API server reads. RBAC rules are API objects you can list, diff and review with standard tooling. For a security program, that difference alone is a reason to move.
Run both together
The RBAC reference gives the shape: set the authorization mode to include RBAC and ABAC, and pass the ABAC policy file.
--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json
In this arrangement a request allowed by either RBAC or ABAC is allowed. That is the safe property for migration, because ABAC keeps working while you add RBAC.
The steps
- Inventory the ABAC policy lines: user or group, namespace, resource and whether read only.
- Translate each into a Role or ClusterRole plus a binding, using the narrowest scope that fits.
- Enable RBAC alongside ABAC.
- Watch the logs. The docs say that once workloads show no RBAC denials in the logs, you can remove ABAC. Check authorization logs at a verbosity that records denials for your version.
- Remove ABAC from the authorization mode and archive the policy file.
The shortcut to avoid
The docs show a permissive RBAC setup that copies an ABAC policy of broad access, by binding cluster-admin to users and the service accounts group. They explicitly call it not a recommended policy. It gets you off ABAC on paper, and keeps the same exposure in a form that is easy to miss.
Binding cluster-admin to all service accounts allows any application full access to your cluster, which the RBAC reference strongly discourages.
Testing before you cut over
Pick a few representative workloads, remove ABAC in a staging cluster, and run their normal paths. Look for 403 responses. Where a workload needs API access, give it its own service account and a narrow role.
Record the change
An authorization mode change is a control change. Capture the before and after configuration, the review and the test results. Safeguard's compliance and evidence automation can hold that record, and policies and gates can check the RBAC manifests in your repository. The cutover itself is a Kubernetes operation.
Who owns the translation
Assign one reviewer for the whole migration, not one per team. ABAC files tend to hold duplicated and overlapping lines, and a single reader spots them. Ask each application owner to confirm what their service needs, and to say what it does not need. Removing unused access during the move is the main security gain, so do not simply copy it across.
Quick check
If ABAC allows a request and RBAC denies it, what happens?
It is allowed while both are enabled. A request allowed by either authorizer proceeds, per the docs.
Sources
Last reviewed: 19 October 2026.
