Shared service accounts are the fastest way to lose an access review

On a platform serving both internal teams and external vendors, the tempting shortcut is a handful of shared service accounts (one per vendor, one per team) because provisioning an individual identity for every external contractor feels like overhead nobody has time for. It works right up until an access review, or an incident, asks the obvious question: who did this. The honest answer, with a shared credential, is “one of six people, we're not sure which.”

Why this specific shortcut costs more in a regulated environment

An access review isn't a formality here; it's a recurring, real event, and “a shared credential used by an unknown subset of a vendor's staff” is close to the worst possible answer to give it. It doesn't just fail the review; it undermines every other control on top of it. RBAC scoping, audit logging, GitOps merge permissions: all of it assumes the identity making a change is a real, singular thing you can reason about. A shared account breaks that assumption at the root, and nothing built on top of it can compensate.

The alternative is more identities, not more process

The fix isn't a heavier approval workflow bolted onto the shared account; it's removing the sharing. Individual, attributable identity for every person who touches the platform, internal or vendor, scoped with least privilege to exactly the namespace or project they need. Where the engagement itself is time-boxed, the identity should be too: a vendor's access should expire when their contract does, not linger as a stale credential someone has to remember to revoke six months later.

The mechanics that make it practical rather than painful

• Federate vendor identity through the same identity provider used for everyone else, instead of issuing local cluster accounts that live outside central tracking.
• Map groups and roles to least-privilege RBAC bindings scoped per project, not cluster-wide access granted once and never revisited.
• Make offboarding a deletion of the identity itself, not a hope that someone remembers to rotate a shared password after a contract ends.

The tradeoff, stated honestly

This is more identities to create and more entries in an identity provider to manage than a handful of shared accounts. That administrative cost is real. It's also smaller, by a wide margin, than the cost of an access review that can't answer its most basic question, or an incident postmortem that ends at “we don't know which of the vendor's engineers had this key.”

Least-privilege identity for internal teams and external vendors isn't a compliance checkbox. It's the property that makes every other access control on the platform actually mean something when someone asks who has access, and why.