
How to give access to AWS resources without creating 100s of IAM Users? - rajanpanchal
https://blog.rajanpanchal.net/how-to-give-access-to-aws-resources-without-creating-100s-of-iam-users-ckds91qj100pf97s1gc3v8vwb
======
RegnisGnaw
That is one convoluted solution. Easier:

Federate users to AWS using SAML
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_pr...](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-
console-saml.html)

~~~
pnathan
This is _murder_ to do for the command line. IAM users are the right choice
for CLI.

edit: apparently aws sso assists here!

~~~
Xylakant
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.

~~~
orf
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...](https://chrome.google.com/webstore/detail/saml-to-aws-sts-keys-
conv/ekniobabpcnfjgfbphhcolcinmnbehde?hl=en)

~~~
Xylakant
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.

------
gpapilion
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
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
The peeps at salesforce created this IAM Least Privilege Policy Generator -
[https://github.com/salesforce/policy_sentry](https://github.com/salesforce/policy_sentry)

~~~
deadbunny
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
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.

~~~
ben509
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...](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-
metadata.html)

~~~
viraptor
> 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.

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

------
j45
LoginRadius might be able to point you in the right direction

