Hacker News Reader

Comment by kriops | Hacker News Reader

What about the credentials used to access AWS credentials? I think there's a good case for centralised credentials where they are shared across applications, though I would seriously question the need to share them across applications. But what you're achieving here as far as I can tell is just making secret retrieval more convoluted (for both devs and hypothetical attackers). Not to beat the dead horse, but obscurity != security.

View on HN

When you deploy your code to AWS lambda or EC2 the code can simply access the appropriate secret stores as dictated by the IAM policy. If you haven't bought into AWS as a whole you're right that there's no good reason to use secret manager.

If you're in AWS, you get credentials from the metadata service. If you're outside AWS, workloads assume roles using OIDC. If you still have access keys, generally speaking, you're doing it wrong.

https://aws.amazon.com/blogs/security/access-aws-using-a-goo...

Both the metadata service and assuming a role with a “web identity” still give you an access key along with a session token.

Technically true, but in practice the role means you don't have to care about them. They're an implementation detail that's managed by AWS. Could be flying mice for all the app dev cares.

Sure, under the hood it is still access keys. Very temporarily defined access keys that going the normal happy path means you're not directly handling. What I'm really meaning by my above comment is you're not configuring your workload with ACCESS_KEY=abc123 SECRET_ACCESS_KEY=xyz789.

They aren't configured, but they're not as temporary as one might hope (i.e. they don't rotate on every read, for example), and it's pretty trivial set of exploits to leak them, especially in Kubernetes clusters with incorrectly configured worker nodes.

A much better solution would be for AWS to offer a domain socket or device inside VMs that will sign requests, such that the private material isn't even available to leak.

OIDC uses a client secret, for one.

Ah that's where we have the Credentials for AWS Credentials Service Agent

Just simply pass it a credential and it will provide you the necessary credentials to access the Credentials for AWS Credentials Service

You need to think bigger, as there is surely some limit n beyond which the nested process of retrieving credentialₙ is beyond the reach of attackers.

There are no credential, you are supposed to use identity-based auth: your lambda / ec2 / eks pods etc have a IAM role, so there are no secret in any form

Reply on news.ycombinator.com