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.

▲

otabdeveloper4 4 days ago | parent [-]

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.

▲

noctune 4 days ago | parent | next [-]

You can condition IAM on Nitro attestation, so that's doable (if a lot more work than usual).

▲

cyberax 4 days ago | parent | prev | next [-]

Regular individual systems that run the code inside the AWS generally do not have long-lived tokens. The credentials are ultimately _pushed_ to the systems running the services by a small set of highly secured and monitored privileged systems.

You get to see that even with the regular public AWS/EC2. Instance roles are managed externally from the customers' points of view.

▲

otabdeveloper4 3 days ago | parent [-]

> highly secured and monitored privileged systems

So, ultimately "keys to the castle" aka a long password?

	▲	cyberax 2 days ago \| parent [-]
		It's a bit more complicated :) There are HSMs and code signing thrown into the mix. They went into total overengineering mode when designing it. But ultimately, any realistic design will eventually have systems that have to be trusted. It's just a question of isolating them.

▲

oneplane 4 days ago | parent | prev [-]

If the long-lived token is actually a private key that is non-retrievable and the secrecy and origin is attested by a HSM, I'm fine with that.