[bertjk]

> 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?

[linux2647]

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]

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]

Do you know how they make this work?

[oasisbob]

For example, with containers on AWS ECS:

https://docs.aws.amazon.com/AmazonECS/latest/userguide/task-...

[sebazzz]

So with environment variables.

I had supposed they would create a derived container and put it in a file somewhere.

[tphummel]

my 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]

So really we are just recreating windows auth