It's good to see an article talking about this. A lot of organizations could benefit from using more than one account to enforce security (IAM is hard!) and separation of concerns.<p>It doesn't really explain it but to do this, the root account has to be enrolled for AWS Organization[1]. This is what is being used to handle all the accounts and consolidate the billing. It also allows to create rules span all the accounts. Recently terraform gained support for the Organization API[2] so it's possible to control the account list in a declarative manner.<p>The biggest issue is that now that there are a lot of accounts, the developers need a way to switch between them. Using the IAM assume-role mechanism is a good way to avoid needing a lot of AWS keys per developer.<p>I don't know if I agree with using Okta as it adds another party that now has access to AWS. I don't see the difference between having a AWS secret or and Okta secret in the keychain security-wise. Okta might provide audit logging facilities but so does AWS.<p>In either case you will need to generate a `~/.aws/config` per developer. There is also a Chrome plugin[3] that can read this file format and populate the AWS Console switch role. I don't know if the extension publisher is reputable yet as it gives a lot of access to the extension.<p>[1]: <a href="https://aws.amazon.com/organizations/" rel="nofollow">https://aws.amazon.com/organizations/</a><p>[2]: <a href="https://github.com/terraform-providers/terraform-provider-aws/pull/903" rel="nofollow">https://github.com/terraform-providers/terraform-provider-aw...</a><p>[3]: <a href="https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl" rel="nofollow">https://chrome.google.com/webstore/detail/aws-extend-switch-...</a>
We created something similar in house.<p>Users authenticate to an internal website with ADFS (including MFA) and are then presented with a list of roles where they can either click through to the website assuming a role in that account for an hour, or click an option to access temporary credentials.<p>The AWS roles are deployed from our CI/CD pipeline to all of our AWS accounts, so we don't have to have user accounts anywhere and can still deploy features from our Pipeline without logging in.<p>We are also in the process of setting up automated account provisioning from our HR system, Workday. Based on the users team and job title, they'll be added into an Active Directory group which would then give them access to the resources required for their role.<p>Once complete, this will save the support team a lot of time!
Excellent article thanks for sharing. It's awesome to see someone documenting their experiences with multi-account strategy.
You said you manage account with Terraform, are there any other resource types that you don't give the dev teams access to such as networking? Also, how are you deploying Terraform at scale across all of your accounts?
How are you dealing with software that expect to get aws tokens? Especially with sts AssumeRoles only lasting up to one hour?<p>For example, if you want to run the Athena JDBC driver locally or read something from S3 in a longish (>1h) running Python script.
Atlassian open sourced a tool to help with CLI access when using many AWS accounts through federated roles.<p><a href="https://developer.atlassian.com/blog/2017/12/introducing-cloudtoken/" rel="nofollow">https://developer.atlassian.com/blog/2017/12/introducing-clo...</a>
I am interested in the thought processes behind setting up separate AWS accounts "for GDPR compliance" as opposed to having one AWS account and running multi regions (via VPC etc.) under that account?<p>Is it because teams in different locations (US, EU etc.) can run semi-independently? How do you manage shared resources (e.g. S3 or RDS SQL servers) that need to be accessed from multiple regions, yet still maintain GDPR compliance?
What are best practices for sharing build artifacts (e.g. images in ECR, files in S3) among AWS accounts? Cross-account IAM policies, explicit promotion process to move artifacts between accounts, or something else?
How would this compare to an LDAP, an LDAP with org wide access control can pretty much enable all of this(keeping in mind GDPR & other security concerns) from just 1 AWS account ?
Out of curiosity, how do people handle communication between services that are in different accounts? VPC peering to connect all accounts? Public Internet and OAuth? Another method?
Temporary security credentials from AssumeRole are valid for up to 3600 secs (1 hour). Given that, how do folks handle long running jobs/sessions?
Hey segment, are you aware that you can have several env (dev, stag, prod, ...) on the same AWS account? :p
You can secure each environement with different credentials (IAM) so no need to create several AWS accounts!