top | item 34872771

(no title)

bertjk | 3 years ago

> Eliminate the need to manage and inject API tokens into containers and servers and instead authorize containers and servers to perform those operations.

What does this look like in practice? Can someone provide example scenarios that this is describing?

discuss

order

linux2647|3 years 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

heleninboodler|3 years ago

This. 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.

whartung|3 years ago

Do you know how they make this work?

acedTrex|3 years ago

So really we are just recreating windows auth