How to give access to AWS resources without creating 100s of IAM Users? | Hacker News Reader

How to give access to AWS resources without creating 100s of IAM Users?

blog.rajanpanchal.net

49 pointsrajanpanchal37 comments

That is one convoluted solution. Easier:

Federate users to AWS using SAML https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...

It is like they created a solution specifically to have a blog post.

Agreed. Rolling your own login solution just to federate access to users seems really, really, unnecessary. There are a million other ways in AWS to accomplish the same task without writing any code, or leaving around a random lambda that will likely be forgotten in a few years.

I’ll be implementing something similar soon, and don’t want to overengineer it. Could you please list the top options and their pros and cons? Thank you in advance!

SAML SSO setup is also one of the singlemost convoluted things most people need to do with AWS, but at least you only have to set it up once (per account).

It’s basically a little mini-nightmare, at least when integrating it into G Suite. Burns a big chunk of a day.

I've found it fairly easy to do on a new account with Okta and Terraform. Was probably a pain the first time (don't remember anymore) but it's been 99% automated after that.

Yeah this was really difficult to wrap my head around and get right the first time (and with an old version of Okta's integration)...and I'm saying that having previously written my own SAML Identity Provider from scratch.

It's a lot easier now though and especially now that I understand how it all works.

Okta is the only solution I've used that gives you the flexibility you need to make SSO not a nightmare. G Suite and Rippling are both very half-baked and integrations are often broken or the granularity you're looking for is not possible (they also both seem to treat SAML as a last resort and would rather push you to custom Oauth or other flows instead, making every integration work a little bit differently).

There may be a few others like One Login where this is their entire business like Okta that are also good, I don't have experience with any others.

G Suite works extremely well with Google Cloud at least.

So much so that we don't bother with Okta there. The Okta logins are the G Suite emails anyway.

Auth0 is also awesome

Or OIDC, if SAML gives one a rash: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...

The aws-vault project recently added support for AssumeRoleWithWebIdentity making it cheap to issue yourself disposable credentials: https://github.com/99designs/aws-vault/blob/v6.0.0-beta9/USA... including launching AWS Console links for those Roles: https://github.com/99designs/aws-vault/blob/v6.0.0-beta9/USA...

Kind of speaking to the blog post's intention, I actually don't have any IAM Users in my AWS account

This is murder to do for the command line. IAM users are the right choice for CLI.

edit: apparently aws sso assists here!

There is some tooling around this that makes it a little less painful, for example with okta i use a tool [0] that i only have to worry about once a day usually, and it's not as painful as okta's own tooling.

However, it does require some understanding, standardization, and general competence from those around you as well.

[0] - https://github.com/jmhale/okta-awscli

I use this thing Nike made. Looks pretty similar.

https://github.com/Nike-Inc/gimme-aws-creds

Is this a significant differentiator with GCP? I log into gcloud with the same identity used by the web console and the rest of Gsuite.

I read the article and wondered why they don’t simply grant object access to a group of users using their existing identity, but I’m not as familiar with AWS as I am with GCP.

For interactive cli use (that is: a person sitting at a computer), SSO is directly supported. `aws sso login ` pops up the web browser, starts the sso login flow and temporary credentials are issued for the cli. Has been working pretty neat for us.

I stand corrected, it seems like! Looks like it rolled out last Nov for the named profiles from the RSS feed.

very happy to see work on this front!!

This doesn't work if you use OneLogin with IDP initiated login (and multiple accounts).

Which sucks. We've had to write our own tooling, and you even need to use an extension like this[1] :(

1. https://chrome.google.com/webstore/detail/saml-to-aws-sts-ke...

We used to use something similar (for office365/AzureAD), but the aws cli Version 2.0 in combination with the changes for aws sso late last year made that obsolete. You may want to check again if your case is now supported. I was pleasantly surprised, even though I had to do the saml setup dance again.

Have you considered saml2aws[0]?

[0] https://github.com/Versent/saml2aws

What if the Idp is not SAML compliant

I always wonder about patterns of directly exposing s3. It always seems preferable to me to have that abstracted to a service that only handles file storage and retrieval. It burdens you with the application logic, but provides you the opportunity for portability and allows you tighter limits on s3 access.

I want to minimize the total number of accounts with AWS access, since a configuration error can expose so much.

Second this. If you have nuanced usage of AWS, then minting credentials (hopefully through grant-only roles with expiry) on the reg is the way to go, but for so many cases, people don't need AWS access. They need to do <some thing> where it would be trivial to wrap the thing in a safe and sane, auditable manner.

The peeps at salesforce created this IAM Least Privilege Policy Generator - https://github.com/salesforce/policy_sentry

This looks like the perfect tool for my company, thanks for sharing!

This is great, thanks for sharing.

Now if I could just find something that acts like selinux in permissive logging mode so I can grant : to something in a dev environment run the thing I need to write a policy for and have it log every permission needed to run the thing I just ran. Would simplify policy writing a ton.

Are there any good resources for AWS best practices? Esp for medium sized companies. Esp stuff like best way to separate between production and dev.

If you ask my current company, apparently the answer is to split the company up into 4 goddamn environments, which apparently just slows things down and makes everything more complicated rather than secure.

Or mine. There is no direction, and everything is encumbered with complex business logic so you're waiting weeks for a S3 bucket.

Or mine: creation of EC2 instances or changes to IAM can only be done via JIRA ticket. Happy hacking!

Do we work for the same company? Devs have just been running scripts on personal machines and uploading the output to google drive LOL

I'll toss out my top 10, which are probably applicable to other vendors:

1. Entirely separate accounts for each stage, and, past dev, all stages are identical.

2. Include a beta stage that doesn't have crap developers set up and forgot. Consider not even giving devs write access to it.

3. Deploy all infrastructure from code via cloudformation or terraform. If you have to use scripts, include deletion logic.

4. Enable cloud custodian to chase down untagged resources. Run it aggressively in dev and beta so it doesn't break prod.

5. Deploy code via artifacts so rolling back is trivial.

6. Integ tests to prove your least privileges IAM roles, routing, security groups, etc. are sufficient.

7. Use CloudTrail and flow logs to prove components still need that access.

8. Load testing in beta to find all the AWS limits before you find them in prod. (Especially, load test any blue/green deployments!)

9. Kill alarm spam with fire. If there's a remedy, automate fixing it. If it's not a real problem, make it a metric. Review your metrics.

10. Figure out where your state (e.g. database) lives and doesn't (which should be most components), and the architecture to make your application resilient should become clear.

And a bonus: You have total control over your AWS environment. Rather than deploying pages of configuration, structure your services so they are configured by convention or introspection[1] as much as possible.

[1]: e.g. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-inst...

> Include a beta stage that doesn't have crap developers set up and forgot. Consider not even giving devs write access to it.

Or use iamy model and create users with no rights in a completely separate account. Then grant them AssumeRole on other roles/accounts as needed.

Scott Piper's security maturity roadmap [1] is generally well regarded and outlines some recommendations that I would say are fairly "one-size fits most." AWS also recently released their "Foundational Security Best Practices" in Security Hub. [2]

[1] https://summitroute.com/downloads/aws_security_maturity_road... [2] https://aws.amazon.com/blogs/security/aws-foundational-secur...

https://summitroute.com/downloads/aws_security_maturity_road...

Scott Piper is the definitive AWS security expert, and this is a guide he publishes and maintains. I'd also suggest following him on Twitter, I learn a lot just from his idle tweets.

https://twitter.com/0xdabbad00

With AWS SSO, you can federate with IDPs like Okta, which offers native CLI support.

More info here: https://www.okta.com/blog/2020/05/how-okta-aws-sso-simplifie...

LoginRadius might be able to point you in the right direction

Reply on news.ycombinator.com