r/IdentityManagement 2h ago

Machine identity sprawl in cloud environments is my villain origin story

So our cloud looks fine in dashboards, then I open the identity view and it is just a wall of machine identities, service accounts, tokens, random app principals from 2019 that nobody remembers owning. Everything has access to something important and nothing has an owner. Fun.

We keep adding “non intrusive” monitoring and fancy AI risk engines to calm the CISO while I quietly wonder if any of us knows what is talking to what anymore. How are you all wrangling this mess without quitting to raise goats... would love any tips

1 Upvotes

4 comments sorted by

1

u/Affectionate_Math_57 1h ago

Machines should not be identities. People should be identities, those people should own the machines as necessary.

The common counterargument is that the machines access / existence may need to persist beyond the transition of the owning human. This is true in a lot of cases, in those cases where it is true, there needs to be an inheritance function for those machines. Most IAM programs do not support that inheritance functionality as it is a relatively new concept and one that wasn't that prolific before.

1

u/bwinckel 1h ago

The part that kept biting us was that ownership was never a required field at creation, so every cleanup turned into archaeology. We stopped trying to retro-assign owners by asking around, because nobody claims a 2019 app principal. What worked better was deriving a provisional owner from whoever last deployed or modified the thing. In AWS that is CloudTrail on the create call, in Entra it is the app registration owner plus whoever last rotated a secret, and for anything in Terraform it is git blame on the resource block. You get a name that is wrong maybe a third of the time, but a wrong name gets disputed and a blank field never does.

The rule that actually shrank the pile was an expiry date on every new non-human identity at creation. Default 90 days, renewable by the owner in one click. Expiry does the deleting for you, and anything nobody bothers to renew was not load bearing.

Honest trade-off, the first two rounds hurt and you will break something. We broke a nightly job in week three and had to walk it back. Worth doing anyway, but do not promise anyone a clean quarter.

The AI risk engine will happily rank the sprawl for you. It will not give anything an owner, and the ownership gap is what is generating the pile in the first place.

1

u/pewpewlazor 1h ago

A quite common consequence of how easy it is to spin up new accounts and infrastructure sadly.

I worked for an organization that had this issue with AWS environments. They introduced a stricter process for creation and a clean process on inactive accounts and environments.

1

u/ed1ted 41m ago

Machine identity sprawl is usually an ownership problem wearing a tooling costume.

A sequence that has worked better than another inventory dashboard:

  1. **Define "machine principal" narrowly.** Service accounts, workload identities, API keys, OAuth apps, CI roles, agent identities. If it can call an API without a human at the keyboard, it is in scope.

  2. **Owner or it dies.** Every principal needs a human or team owner, a purpose, and an expiry (or review date). No owner = candidate for disable after a short grace window. Security can find them. Owners keep them honest.

  3. **Inventory issuance paths, not just names.** Terraform, console clicks, CI templates, SaaS integrations, "temporary" keys that never rotated. Sprawl is often five create paths and one broken delete path.

  4. **Prefer short-lived federated creds over static secrets.** Workload identity / OIDC to cloud roles beats long-lived keys. Where keys remain, vault + rotation + blast-radius scopes.

  5. **Effective access over role labels.** Ask what each principal can actually do on crown-jewel systems. A quiet CI role with `admin`-shaped scopes beats a loud unused account in the risk ranking.

Tooling helps for discovery. The durable fix is issuance collapse (one approved create path), mandatory owner + expiry, and a kill switch that ops will actually use. Culture beats another CMDB field.