3 ms·

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

by bertjk 4y 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?

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 ago
  Do you know how they make this work?
  - oasisbob 4y ago
    For 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 ago
      So with environment variables. I had supposed they would create a derived container and put it in a file somewhere.
  - tphummel 4y ago
    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 4y ago
  So really we are just recreating windows auth
- heleninboodler 4y 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.

by bertjk 4y ago

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 ago
Do you know how they make this work?
- oasisbob 4y ago
  For 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 ago
    So with environment variables. I had supposed they would create a derived container and put it in a file somewhere.
- tphummel 4y ago
  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 4y ago
So really we are just recreating windows auth
heleninboodler 4y 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.