5 ms·
Example: you don’t need AWS keys to write to SQS because the EC2 instance has an identity (“principal”) applied to it, and SQS has been configured trust request
by linux2647 4y ago
Example: you don’t need AWS keys to write to SQS because the EC2 instance has an identity (“principal”) applied to it, and SQS has been configured trust requests from said identity for some set of queues. It’s typically cloud-specific in the implementation and the resources being requested
- whartung 4y agoDo you know how they make this work?
- oasisbob 4y agoFor example, with containers on AWS ECS: https://docs.aws.amazon.com/AmazonECS/latest/userguide/task-iam-roles.html https://docs.aws.amazon.com/AmazonECS/latest/userguide/task-...
- sebazzz 4y agoSo with environment variables. I had supposed they would create a derived container and put it in a file somewhere.
- tphummel 4y agomy understanding is that the major public clouds operate Public Key Infrastructure on end users' behalf. It feels like magic because there are large teams of very smart and capable people making it feel like magic.
- acedTrex 4y agoSo really we are just recreating windows auth
- heleninboodler 4y agoThis. To state it a slightly different way, instead of "create me an instance and inject the following AWS credentials in it" and then having the application running on that instance know where to look to get the AWS credentials, you go "create me an instance and assign it an IAM Role of 'webserver'" and then you write access policy that says "any of my instances with the role 'webserver' can access this bucket/database/queue." The magic is your app uses the SDK to say "assume the 'webserver' role" and it does this under the covers by going out and finding ephemeral keys that AWS injects into your instance via the metadata service. No shared keys == goodness.