Comment by otabdeveloper4
1 month ago
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.
You can condition IAM on Nitro attestation, so that's doable (if a lot more work than usual).
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.
> highly secured and monitored privileged systems
So, ultimately "keys to the castle" aka a long password?
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.
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.