5 ms·

> Furthermore, AWS and Google Cloud’s metadata services only support one role/service account per instance. If you have multiple services that require different

> Furthermore, AWS and Google Cloud’s metadata services only support one role/service account per instance. If you have multiple services that require different permissions on an instance, they’ll have to share, which is poor security practice. A service may get access to something it doesn’t need and audit logs will be less useful. There’s no such limitation with static file-sourced credentials. Bit of a head-scratcher. If you run multiple services on a VM, why not issue each of them identities of their own, rather than relying on the IMDS identity? If you need separate identities on the same machine for your security posture, then the complexity of setting that up is largely handled for you by IRSA: https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-f... Even the logging service should not be using the IMDS identity. The IMDS identity should be very much locked-down, something like AmazonSSMManagedInstanceCore if I recall correctly.

scarface_74 3y ago
Because not everyone uses EKS?
- jsty 3y ago
  Then, as alluded to in the last section, you can link IAM to an OIDC identity provider to hand your workloads temporary role credentials https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...
kevincox 3y ago
> why not issue each of them identities of their own Because the easy ways of doing this are not nearly as secure as the short-lived credentials provided by the metadata services in these clouds. With 5-min credential expiry you can know that if a developer logs into the VM (for debugging or troubleshooting or whatever) after 5min they can no longer invisibily impersonate that role. This makes audit logging and similar much more powerful. I've frequently seen long-lived credentials being used as an alternative and this way anyone who have ever logged into any VM with that key can invisibly impersonate that service forever. You can do this by writing your own credentials manager but this is much more work, harder to make as reliable as the one provided by the IAAP provider and you still need a root of trust somewhere. Relying on the metadata service moves the root of trust to something ephemeral and managed which is highly valuable.

scarface_74 3y ago

Because not everyone uses EKS?

jsty 3y ago
Then, as alluded to in the last section, you can link IAM to an OIDC identity provider to hand your workloads temporary role credentials https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...

kevincox 3y ago

> why not issue each of them identities of their own Because the easy ways of doing this are not nearly as secure as the short-lived credentials provided by the metadata services in these clouds. With 5-min credential expiry you can know that if a developer logs into the VM (for debugging or troubleshooting or whatever) after 5min they can no longer invisibily impersonate that role. This makes audit logging and similar much more powerful. I've frequently seen long-lived credentials being used as an alternative and this way anyone who have ever logged into any VM with that key can invisibly impersonate that service forever. You can do this by writing your own credentials manager but this is much more work, harder to make as reliable as the one provided by the IAAP provider and you still need a root of trust somewhere. Relying on the metadata service moves the root of trust to something ephemeral and managed which is highly valuable.