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.