RBAC role overlap happens when two or more roles grant the same permission, so removing one role doesn't actually take the access away. Combined with old role assignments that nobody cleans up, it leaves people holding permissions their current job no longer needs. In role-based access control (RBAC), people get permissions through roles instead of one at a time. That makes access easy to grant. It also makes access easy to forget.
This guide follows one example from start to finish. Dana moved from Finance to Marketing months ago, yet she can still open the payroll folder. We'll trace that symptom to its two causes, walk through how to diagnose and fix it, and finish with the habits that stop it from coming back.
- Extra access causes no errors, so it stays hidden until someone looks for it on purpose.
- Overlap means one permission comes from several roles, and removing one of them changes nothing.
- Old assignments pile up because every job move adds roles and almost none get removed.
- Fix it in this order: list every role, compare the combined access to the job, remove leftovers, verify, then give each permission one source.
- Prevent it with scheduled access reviews, role removal tied to job changes, and roles assigned through groups.
- 0:00Intro
- 0:29Access that should be gone
- 1:29Overlapping roles grant access twice
- 2:31Old assignments never leave
- 3:30It looks fine from outside
- 4:28List every role each user holds
- 5:26Compare access against the real job
- 6:25Remove stale assignments
- 7:23Confirm the access is really gone
- 8:21Give each permission one clear source
- 9:17Narrow a role to its job
- 10:15Same users, cleaner access
- 11:04Make access reviews a routine
- 12:04Same symptom, different cause
- 12:48The whole fix on one slide
- 13:19Fewer, clearer roles keep access honest
Why can someone still access data after changing jobs?
The symptom is quiet. Nothing crashes and no alert fires. Someone simply opens data they lost the right to months ago, and the system lets them in. Every request still works, so no error message or warning banner tells you something is wrong.
Here is an access log. Dana works in Marketing today, yet she just opened the payroll folder, and the system answered allowed. She left Finance months ago, so on paper this access should be gone. A blocked user complains within minutes. An allowed request looks completely normal. That is why extra access can sit unnoticed for years, until an audit or an incident brings it to light.
The risk is real even if Dana means no harm. Every extra permission is a door that an attacker, or a simple mistake, can walk through.
- No warning signs: allowed requests raise no errors.
- Real risk: unused access is still usable access.
# access log, today
user: dana team: Marketing
action: READ /finance/payroll
result: ALLOWED
# Dana left Finance months agoCause one: RBAC role overlap grants access twice
The first root cause explains why access survives after someone tries to remove it. A permission doesn't belong to just one role. It can come from several roles at once, and the user keeps it as long as any one of those roles remains.
Dana is assigned Finance Reader and also Reports Viewer. Both roles grant the same permission, read payroll, and that permission opens the payroll folder. That gives her two separate paths to one destination. An admin removes Finance Reader, closes the ticket and assumes she's locked out. Because Reports Viewer still grants read payroll, nothing has changed for Dana.
Overlap usually grows out of quick fixes. Someone needs access fast, so a new role is created by copying an old one. Over time, the same permission spreads across many roles, and nobody remembers why.
Cause two: old role assignments never leave
Overlap explains why removal fails. The second cause explains why there is so much to remove. Roles are added at every job move, but they are almost never taken away. Think of a keyring. Each new job adds a key, nobody asks for the old ones back, and the ring keeps getting heavier.
Dana joins Finance and gets Finance Reader. That's correct. She moves to Marketing and gains Marketing Editor, because her new work is urgent. Removing Finance Reader isn't urgent, so it never happens, and now she holds both. When she eventually leaves, her main login is disabled. That feels final, but assignments in other apps, cloud accounts or databases may still exist.
This stays hidden for two reasons. People report missing access because it stops their work, but nobody files a ticket saying they have too much. Roles also live in many places, including cloud consoles, business apps, databases and file shares. No single screen shows everything.
How to list every role a user holds
Diagnosis starts with a simple rule: you can't fix what you can't see. For each user, list every role they hold, everywhere. Don't try to audit the whole company on day one. Start with one user or one team. A small list that's truly complete is more useful than a huge one that's half finished.
On Azure, a single command lists every role assignment for Dana, and the all flag covers every scope instead of just one. On Kubernetes, getting rolebindings with the -A flag does a similar job across all namespaces. A common mistake is checking only the place you usually work. Roles can be granted on a whole account, a project or one folder, and also through groups. If you skip any of these, you can miss the duplicate.
Write the results down in a simple sheet with the user, the role and where it was granted. That sheet becomes your map for every step that follows.
- Include accounts, projects, folders and group memberships.
- Record user, role and scope for each assignment.
# Azure: every role for one user
az role assignment list \
--assignee dana@corp.com \
--all --output table
# Kubernetes: all namespaces
kubectl get rolebindings -ACompare combined access against the real job
A list of role names doesn't tell you much on its own. Combine all of a person's roles into one set of permissions, then compare that set with what their job actually requires. The question is simple: what can this person do today that their job doesn't need? Whatever falls into that gap is what you'll remove.
For Dana, the list shows three roles. Combined, they grant payroll plus campaigns. Her Marketing job needs campaigns only, so payroll is the gap. Always judge the combined total. One role on its own can look harmless, and the problem only shows up when you add them together.
Don't rely on role names to decide what the job needs, because names can be misleading. Ask the person's manager. A short conversation with someone who knows the work is more reliable than guessing from labels.
Remove stale assignments and confirm access is gone
The first fix is usually the easiest: remove leftover roles from old jobs. Work through them one at a time. If something unexpected happens, you'll know exactly which change caused it and can put it back in seconds. On Azure, removing Dana's Finance Reader role means naming the person, the role and the scope. The scope matters because the same role can be assigned in several places.
Start with people who have left. Nobody is watching those accounts, so they carry the most risk. The decision is also easy, because there's no job left to protect. As you go, record what you removed, from whom and why, so the next audit can follow your work.
Then verify. A tool reporting success doesn't prove the access is gone. Give the change a moment to take effect, list the user's roles again, and then try opening the resource as that user or with a matching test account. If it's still allowed, another role or group likely grants the same permission. That's overlap, and it becomes the target for the next step.
- Remove one leftover at a time.
- Handle leavers first.
- Some systems keep sessions or tokens alive, so sign the user out and retest.
# remove Dana's leftover Finance role
az role assignment delete \
--assignee dana@corp.com \
--role "Finance Reader" \
--scope <finance-resource-group-id>Fix role overlap: give each permission one clear source
The second fix addresses overlap directly. The goal is for every permission to have one clear source, so that removing a role reliably removes the permission. To get there, flip your view. Instead of asking what each user has, ask which roles grant each permission. For a sensitive permission like read payroll, list every role that grants it. When you sort by permission, duplicates are easy to spot.
Then deal with each duplicate. If two roles are nearly identical, merge them. If a role grants something outside its purpose, narrow it. In our example, Reports Viewer granted read reports and read payroll. After narrowing, it grants read reports only. Payroll now has one source, Finance Reader, and anyone who needs payroll gets that role on purpose. The format in the example is simplified, since every platform writes roles differently, but the idea applies everywhere.
Narrowing is often better than deleting, because many people use Reports Viewer legitimately. Move users to the cleaned-up roles, re-run your diagnosis checks, and ask a real user of the role to try their everyday tasks before you call it done.
- Map permissions to roles, not the other way round.
- Merge near-identical roles; narrow roles that reach too far.
- Test that nobody lost access they really need.
# before: reports-viewer
permissions: [read:reports, read:payroll]
# after: payroll removed
permissions: [read:reports]
# payroll now only in finance-readerHow to keep access clean with routine reviews
After both fixes, the people and jobs are the same, but the structure is cleaner. Before, Dana held three roles, payroll came from two of them, and removing one changed nothing. After, she holds one Marketing role, payroll has one source, and removing a role actually removes access. Any admin can now quickly answer who has a given access and why, which is also what auditors ask.
Without new habits, leftovers creep back. Put access reviews on a regular schedule. On each review date, pull every assignment, have each team's manager decide what to keep or remove, then clean up and verify as before. Also tie removal to job changes. When HR records a move or an exit, role removal should start as part of that same process.
Finally, assign roles to groups such as Marketing Team rather than to individuals. When someone moves, changing their group updates their access in one step.
Roles look clean but access remains: what to check
Sometimes you clean up every role and the access still won't go away. That usually means a different problem with the same symptom. Before you redesign your roles, check four other common causes.
Inherited access comes from a role set on a parent folder, project or account, which then flows down to everything inside it. A direct grant is a permission given outside any role, so you'll find it in the resource's own sharing settings. Anyone-with-the-link sharing can let people in without any role at all. An old session or token may simply not have expired yet. Most of the time, leftover access is hiding in one of these four places.
- Inherited from a parent scope
- Direct grant outside any role
- Shared link
- Old session that hasn't expired
Key takeaways
- Extra access is silent, so you have to look for it on purpose.
- A permission stays as long as any role that grants it remains.
- List every role across every scope, then compare the combined access to the real job.
- Remove leftovers one at a time and always test that access is really gone.
- Give each sensitive permission one clear source by merging or narrowing roles.
- Schedule reviews, tie removal to job changes, and assign roles through groups.
Frequently asked questions
What is RBAC role overlap?
It's when two or more roles grant the same permission. The user keeps that permission as long as any of those roles is still assigned, so removing just one role doesn't remove the access.
Why does a user still have access after I removed their role?
Usually another role or group grants the same permission. It can also be inherited access from a parent scope, a direct grant, a shared link, or a session that hasn't expired yet.
What are stale role assignments?
They are roles left over from a previous job or team. They build up because access is added when people move, but old roles are rarely removed at the same time.
How do I check whether a role removal actually worked?
Give the change a moment to take effect, list the user's roles again, and then try to open the resource as that user or with a matching test account. If access lingers, sign the user out and test again.
Should I delete overlapping roles?
Not always. Narrowing a role so it only covers its intended job keeps it useful for the people who rely on it, while closing the extra path to the permission.
How often should access reviews happen?
Pick a regular schedule your team can keep and put it in the calendar. Reviews work best combined with role removal that starts automatically when HR records a team move or exit.
