[collabs]

Something I don't understand is the absolute phobia of service accounts. There are things that need to happen regardless of who is doing it. Emails need to get sent every day with reports, for example.

Forcing these workflows into the nonsense security theater of "we can't have service accounts" is stupid and unproductive. So every time we fire or lay off the person whose name is on the automation, we need to rotate the keys? What is the benefit here?

If you are screaming "managed identity" here, I have a bridge to sell you because clearly even Microsoft has not been able to figure out or implement managed identities for internal workloads... Well not as of 2022, at least.

[theamk]

Service accounts are great! I just wish instead of having a password which gets shared around via 1password, there were a clear permission list ("this is a service account.. "real" users X, Y, X can login as it")

Seems like it's just Microsoft that cannot figure it out. AWS had roles forever, fully supported from web console or CLI. But when I request Azure service account, I am handed username and password.

[kkl]

> "we can't have service accounts"

To be clear: This is not my position! I advocate for service accounts in my post:

> It is much harder to reason about, say, the security of an arbitrary Engineer's laptop than it is an EC2 instance that exists exclusively to tell KMS to sign something.

> So every time we fire or lay off the person whose name is on the automation, we need to rotate the keys?

If a person previously had access to the key and knowledge of the key gives you control over that automated workflow, is that key (and by extension that workflow) still worth trusting?

[anon7000]

Totally, but my service accounts own the api keys. But keys are still annoying to rotate. You know what’s not annoying to rotate? Short-lived tokens with very limited scope that get assigned more on demand