AWS had switched from using something like this ("injection tokens") to just regular IAM roles, though managed by the AWS.
The only special permission that services (actually, the AWS accounts that they use) inside the AWS have is access to "service principals". The service roles inside customer accounts then use them to grant access.
AWS IAM is painful, but it shows that you can design a secure permission system.
You can add many layers of indirection, but unless you're actually authenticating that a system service is using the credentials (and not, say, a user or a script) then it boils down to a long-lived token at the end.
My NSL detector is off the charts here.
For anyone not familiar with the abbreviation: https://www.eff.org/issues/national-security-letters/faq
> impersonation tokens, called “Actor tokens”, that Microsoft uses in their backend for service-to-service (S2S)
Literally every single "security" framework uses God-mode long-lived tokens for non-human identities.
(Except for SPIFFE, but that's a niche thing and used only for Kubernetes bullshit.)
The whole field of "security" is a farce staffed by clowns.
AWS had switched from using something like this ("injection tokens") to just regular IAM roles, though managed by the AWS.
The only special permission that services (actually, the AWS accounts that they use) inside the AWS have is access to "service principals". The service roles inside customer accounts then use them to grant access.
AWS IAM is painful, but it shows that you can design a secure permission system.
You can add many layers of indirection, but unless you're actually authenticating that a system service is using the credentials (and not, say, a user or a script) then it boils down to a long-lived token at the end.
5 replies →