Hacker News Reader

Comment by watermelon0 | Hacker News Reader

When allowing 3rd parties to access your AWS resources, IAM keys are in most cases the only way to achieve this.

For example, most CI/CD systems don't support OIDC yet, so you have to add IAM keys to them. GitHub Actions is a notable exception here.

View on HN

I'd push back on that norm.

I listened to a vendor pitch for a product that would need access to my cloud assets. They wanted me to export auth keys as strings and hand them over, with super high access rights. I laughed and pointed out OIDC, Workload Identity Federation, cross account user identities... etc as more secure methods that didn't require handing over any secrets.

Multi-billion dollar vendor; their engineer just gave me a blank stare as if the notion was completely novel. It's not. None of the products/integrations I build require a customer to share their cloud creds to work w/ their cloud assets.

2020 is calling...

Maybe not OIDC, but most support SAML, which is good enough.

There's also SAML/OAuth2/OIDC proxies you can use along with role-specific service accounts, so even legacy app access can be audited and controlled with temporary sessions. One OAuth2 reverse proxy can authenticate entire subdomains worth of web apps. (https://oauth2-proxy.github.io/oauth2-proxy/)

If some proprietary app says they only support static IAM keys, they can easily enable the AWS SDK to transparently handle AWS STS temporary credentials. You just authenticate with some other app (say, saml2aws) and the tokens are cached locally, and the AWS SDK takes care of the rest. (You can also configure the AWS SDK's credential_process feature to make that seamless)

Cross-account AWS access can be granted to specific roles to be assumed with specific IAM policies. No keys or users at all.

If the third party has their own IAM users, you can create a cross-account trust relationship where you allow their IAM entity to assume a (scoped-down) role in your account. Then they are able to retrieve temporary credentials to assume this role.

One reason people don't like doing this is that by assuming this role you lose all the privileges in your own account. It's not something you can't overcome (e.g. by using separate credential chains in different parts of the app), but people are lazy.

You don't 'lose' anything, you gain a second set of creds that have an independent lifecycle. The only time this is awkward is if you're using the web console b/c you need to keep going through the assume role/return links.

Not to mention you can just use a new --profile for that session and switch between them with a single argument or environment variable. I don't think it's possible to get easier than that :)

That's what I meant, but admittedly I communicated it poorly - you need to reconfigure various bits of the code to use this credentials chain, which can sometimes not be supported by poorly written tools.

Reminds me of this I stumbled across for ngrok:

> Can I run my own ngrok server? > Yes, kind of. You may license a dedicated installation of the ngrok server cluster for commercial use. You provide us with keys to an AWS account and we will install the server cluster software into that account

I have no idea how common this pattern is, but personally, the idea of giving someone else AWS creds that aren't _very_ locked down scares me.

I never understood the point of self-hosting ngrok. Isn't its entire value proposition that it lets you borrow a stable public IP to host something with when you don't have one of your own?

This also occurs when your AWS resources need to access 3rd party services. Some services don't have temporary key support.

If you need to access 3rd party services from your AWS account you can at the very least put those credentials into Secret Manager or SSM Parameter Store, so that your application retrieves them at runtime when it needs to - no need to store them with the app.

Reply on news.ycombinator.com