7 ms·

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

49 points by rajanpanchal 6y ago

RegnisGnaw 6y ago
That is one convoluted solution. Easier: Federate users to AWS using SAML https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...
- brian_herman__ 6y ago
  It is like they created a solution specifically to have a blog post.
  - hcazz 6y ago
    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.
    - moltar 6y ago
      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!
      - deleted 6y ago
        [deleted]
- sneak 6y ago
  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.
  - marcinzm 6y ago
    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.
    - busterarm 6y ago
      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.
    - cactus2093 6y ago
      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.
      - busterarm 6y ago
        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.
      - dkdk8283 6y ago
        Auth0 is also awesome
- mdaniel 6y ago
  Or OIDC, if SAML gives one a rash: 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... 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/USAGE.md#assuming-roles-with-web-identities 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/USAGE.md#logging-into-aws-console 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
- pnathan 6y ago
  This is murder to do for the command line. IAM users are the right choice for CLI. edit: apparently aws sso assists here!
  - avh02 6y ago
    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 https://github.com/jmhale/okta-awscli
    - joombaga 6y ago
      I use this thing Nike made. Looks pretty similar. https://github.com/Nike-Inc/gimme-aws-creds https://github.com/Nike-Inc/gimme-aws-creds
  - 0xEFF 6y ago
    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.
  - Xylakant 6y ago
    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.
    - pnathan 6y ago
      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!!
- rajanpanchal 6y ago
  What if the Idp is not SAML compliant
gpapilion 6y ago
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.
- xyzzy_plugh 6y ago
  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.
sandGorgon 6y ago
The peeps at salesforce created this IAM Least Privilege Policy Generator - https://github.com/salesforce/policy_sentry https://github.com/salesforce/policy_sentry
- Aaronstotle 6y ago
  This looks like the perfect tool for my company, thanks for sharing!
- deadbunny 6y ago
  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.
x87678r 6y ago
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.
- sushshshsh 6y ago
  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.
  - lykr0n 6y ago
    Or mine. There is no direction, and everything is encumbered with complex business logic so you're waiting weeks for a S3 bucket.
    - MG9991ep545a1l3 6y ago
      Or mine: creation of EC2 instances or changes to IAM can only be done via JIRA ticket. Happy hacking!
      - sushshshsh 6y ago
        Do we work for the same company? Devs have just been running scripts on personal machines and uploading the output to google drive LOL
- ben509 6y ago
  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-instance-metadata.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-inst...
j45 6y ago
LoginRadius might be able to point you in the right direction
frankie88chen 6y ago
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-simplifies-admin-and-adds-cli-support/ https://www.okta.com/blog/2020/05/how-okta-aws-sso-simplifie...

49 points by rajanpanchal 6y ago

That is one convoluted solution. Easier: Federate users to AWS using SAML https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...

brian_herman__ 6y ago
It is like they created a solution specifically to have a blog post.
- hcazz 6y ago
  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.
  - moltar 6y ago
    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!
    - deleted 6y ago
      [deleted]
sneak 6y ago
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.
- marcinzm 6y ago
  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.
  - busterarm 6y ago
    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.
  - cactus2093 6y ago
    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.
    - busterarm 6y ago
      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.
    - dkdk8283 6y ago
      Auth0 is also awesome
mdaniel 6y ago
Or OIDC, if SAML gives one a rash: 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... 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/USAGE.md#assuming-roles-with-web-identities 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/USAGE.md#logging-into-aws-console 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
pnathan 6y ago
This is murder to do for the command line. IAM users are the right choice for CLI. edit: apparently aws sso assists here!
- avh02 6y ago
  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 https://github.com/jmhale/okta-awscli
  - joombaga 6y ago
    I use this thing Nike made. Looks pretty similar. https://github.com/Nike-Inc/gimme-aws-creds https://github.com/Nike-Inc/gimme-aws-creds
- 0xEFF 6y ago
  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.
- Xylakant 6y ago
  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.
  - pnathan 6y ago
    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!!
rajanpanchal 6y ago
What if the Idp is not SAML compliant

gpapilion 6y ago

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.

xyzzy_plugh 6y ago
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.

sandGorgon 6y ago

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

Aaronstotle 6y ago
This looks like the perfect tool for my company, thanks for sharing!
deadbunny 6y ago
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.

x87678r 6y ago

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.

sushshshsh 6y ago
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.
- lykr0n 6y ago
  Or mine. There is no direction, and everything is encumbered with complex business logic so you're waiting weeks for a S3 bucket.
  - MG9991ep545a1l3 6y ago
    Or mine: creation of EC2 instances or changes to IAM can only be done via JIRA ticket. Happy hacking!
    - sushshshsh 6y ago
      Do we work for the same company? Devs have just been running scripts on personal machines and uploading the output to google drive LOL
ben509 6y ago
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-instance-metadata.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-inst...

j45 6y ago

LoginRadius might be able to point you in the right direction

frankie88chen 6y ago

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-simplifies-admin-and-adds-cli-support/ https://www.okta.com/blog/2020/05/how-okta-aws-sso-simplifie...