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.
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.
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.
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.
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.
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.
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.
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.
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]
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.
38 comments
[ 0.26 ms ] story [ 78.7 ms ] threadFederate users to AWS using SAML https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...
It’s basically a little mini-nightmare, at least when integrating it into G Suite. Burns a big chunk of a day.
It's a lot easier now though and especially now that I understand how it all works.
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.
So much so that we don't bother with Okta there. The Okta logins are the G Suite emails anyway.
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
edit: apparently aws sso assists here!
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/Nike-Inc/gimme-aws-creds
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.
very happy to see work on this front!!
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...
[0] https://github.com/Versent/saml2aws
I want to minimize the total number of accounts with AWS access, since a configuration error can expose so much.
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.
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...
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.
[1] https://summitroute.com/downloads/aws_security_maturity_road... [2] https://aws.amazon.com/blogs/security/aws-foundational-secur...
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
More info here: https://www.okta.com/blog/2020/05/how-okta-aws-sso-simplifie...