I've used the ASEA to get a number of organizations setup. I prefer it to Control Tower (it can be installed on top of CT). The ASEA is open source and written in AWS cdk so it can be forked and modified if needed.
The guy or gal that's been working on it the last two years has slowly been working through my bucket list.
If I can just get guardrails that configure the basic AWS security foundation stuff like password policies, I'll be satisfied. And oddly enough, the CloudFormation coverage for this stuff is abysmal. We don't even allow IAM users in the member accounts, but we really need to check off this compliance box.
If config can go this long with half-assed implementation I don’t see why control tower is going to fare better with more adoption. Most large enterprises are going to want to roll their own anyway.
Short explanation: it allows you to access a Linux instance via SSH using SSM as an IAM controlled proxy or use RDP for Windows.
You don’t need ingress access to your instance or even egress internet access if your security policies mandate it as long as you set up the correct service endpoints.
Also, just use Control Tower and federate it with your IDP - Active Directory, Okta, etc.
A lot of us are busy solving business needs in smaller companies/startups and don't have the time nor expertise to learn every single AWS service and come up with a justification for utilizing it.
I agree to an extent, though SSH may make sense for break-glass usage. SSM was unavailable during the large scale control plane outage last December, and I saw clients that would have been dead in the water without SSH as an alternative. That said, it's important to really think through how to provide that secondary layer without weakening the overall security posture. It's possible, but it does take work.
These type of articles make me wanna quit doing anything in IT.
It's not a criticism of the author, more the current state of technology in AWS.
I'd really like to have just 1 AWS account where I can see and do everything there and not keep switching and think about account IDs or which account has what S3 bucket/server whatever.
It's always a tradeoff between blast radius and (in)convenience.
With everything in one account someone might accidentally destroy your production environment. That'll be awkward to explain. And with IAC, it could be as simple as one change to a VPC config that recreates instead of updates the VPC.
In normal IT (not Twitter) you usually have a production and test environment at least. The inconvenience more than makes up for accidentally destroying something in production. And before you say anything, if you haven't done that you haven't been in IT for long enough.
However, if you want to do it your way you should become the director and make it that way. You'll be sorry, but that'll be on your head.
I'm not sure if that's possible, but I haven't checked.
Same. My current company has the same problem, which is that they continually layer additional complexity onto their previous architectural mistakes to try and mitigate them. This results in a complicated system where different independent parts all interact with each other like a rube goldberg machine. The dynamics of the resulting system become sort of perilous and unknowable, and it paralyzes future changes because nobody can predict the nth order effects.
Then do it. Why does your activity in IT depend on what someone on the internet says? For the rest of us, multi-account setups offer a large number of advantages that outweigh the inconveniences and we have built tooling to deal with most of those anyway.
The really frustrating things is that while AWS make the "Account" their best isolation layer they make managing those accounts with their tooling absolutely awful.
Very nice write up. As a billing guy I especially liked the tip about using resource policies to enable cross-account access and save on KMS request costs.
There's one issue with companies using hundreds of AWS accounts if you're a vendor to them: integrating services. Some folks here may be interested in a technique called "CloudFormation StackSets" which can deploy bits of infrastructure to multiple AWS accounts in one command. Vantage uses this to setup our billing integration and we wrote up the method here, https://www.vantage.sh/blog/using-cloudformation-stacksets-t...
For an IdP it seems like Dex combined with an LDAP server would be the simplest and most flexible solution. For reliability, I'm curious about throwing together a really simple LDAP server that stores records in AWS S3. That way your IdP can be trivially replicated with as much reliability as you want and nearly no maintenance. (Dex's storage can be Etcd, but I would also look to implement S3 storage)
Honestly, having lived a parallel life to the Windows ecosystem, TIL about “red forest.” I do think, though, that cross-account AWS actions are much more first-class than it sounds like jumping between forests ever was.
> Don’t do this! Any principal in your management account, by default, is able to assume the OrganizationAccountAccessRole in each and every one of the accounts created using the organizations:CreateAccount API.
I should note that if you use AWS Control Tower Account Factory to create the member accounts then this role does not get created.
The "Audit" account that is created by Control Tower is probably the best one to serve as the Administrative Access Account
> Any principal in your management account, by default, is able to assume the OrganizationAccountAccessRole in each and every one of the accounts created using the organizations:CreateAccount API.
This is an untrue statement. For a principal in the management account to assume OrganizationAccountAccessRole, they need to have a principal-based policy that gives sts:AssumeRole permissions for it. Otherwise, great article. We use this pattern at $DAYJOb
What's this like on Google Cloud? Would you create a project to get into other projects and would that achieve most of what this achieves? And would you use a GSuite address so you don't log into the console just by logging into the email?
Everything in GCP is built atop the Google Auth system and tied to a GSuite domain. It’s Org->Folder->Project hierarchy is very similar to AWS Orgs. However, it’s far easier from there. IAM is tied to your gsuite email, and service accounts are also email addresses. One never needs to login with different creds to access another project. You just use your Google login or activate a service account.
Projects are a really flexible abstraction. My company has one for every stage for every team plus specialized projects for net/VPC, GCR, logs, etc, hundreds in total. We’re about halfway through the F500 list. Projects are a nice abstraction and getting the setup OP described is a lot more idiomatic to GCP.
You can’t have nested projects, but for the purposes of organizations there is folders and orgs, which are container of containers.
GCP’s IAM somewhat addresses the isolation and scope problem mentioned in the article. Not all GCP apis, atleast with respect to OAuth2, properly utilize IAM, insofar that they require overly power OAuth2 scopes. For example, to list cloud functions you need permissions to create and edit, too. That’s broken.
In GCP, many orgs find themselves proliferating in projects because GCP’s billing is abstruse. People isolate resources to projects so they know how much specific services actually cost.
This in turn presents another problem. GCP Web Console’s search doesn’t index well. For example, substring search doesn’t work on far too many resources. VMs are the exception, but we think this is inverted. Substring search should work on every resource, not be exceptional. Historically it didn’t even do cross project search. This is frankly not acceptable for a search company.
We created a second GSuite for GCP at Slack because we didn’t want email and other corp IT assets to be mixed into what could’ve (but didn’t) become production infrastructure.
For enterprises it seems this is already baked-in, ie. when you're a Google Workspace (previously GSuite) user, your project selector has an inherent hierarchy stemming from the domain, ie. example.com -> project1, project2, etc. and, in my limited experience, switching between accounts on the command line is pretty good. But this article still makes a good point about keeping different environments in different siloed projects.
What tool do people here use to search across AWS accounts?
Disclaimer: we are building a search engine to search for resources across “workspaces”. In AWS, this unit is the Account. In GCP, this unit is the Project.
flyinprogrammer|3 years ago
If we all started using Control Tower perhaps they'd get funded enough to continue to build it out and make it awesome.
wrnu|3 years ago
I've used the ASEA to get a number of organizations setup. I prefer it to Control Tower (it can be installed on top of CT). The ASEA is open source and written in AWS cdk so it can be forked and modified if needed.
thedougd|3 years ago
If I can just get guardrails that configure the basic AWS security foundation stuff like password policies, I'll be satisfied. And oddly enough, the CloudFormation coverage for this stuff is abysmal. We don't even allow IAM users in the member accounts, but we really need to check off this compliance box.
rcrowley|3 years ago
jcims|3 years ago
dmak|3 years ago
scarface74|3 years ago
Don’t do this. I can’t think of a single reason that anyone ever needs to SSH directly into a server on AWS in 2022.
Use System Manager Session Manager
https://docs.aws.amazon.com/systems-manager/latest/userguide...
Short explanation: it allows you to access a Linux instance via SSH using SSM as an IAM controlled proxy or use RDP for Windows.
You don’t need ingress access to your instance or even egress internet access if your security policies mandate it as long as you set up the correct service endpoints.
Also, just use Control Tower and federate it with your IDP - Active Directory, Okta, etc.
datalopers|3 years ago
cjcampbell|3 years ago
throwawaaarrgh|3 years ago
tedk-42|3 years ago
It's not a criticism of the author, more the current state of technology in AWS.
I'd really like to have just 1 AWS account where I can see and do everything there and not keep switching and think about account IDs or which account has what S3 bucket/server whatever.
manv1|3 years ago
With everything in one account someone might accidentally destroy your production environment. That'll be awkward to explain. And with IAC, it could be as simple as one change to a VPC config that recreates instead of updates the VPC.
In normal IT (not Twitter) you usually have a production and test environment at least. The inconvenience more than makes up for accidentally destroying something in production. And before you say anything, if you haven't done that you haven't been in IT for long enough.
However, if you want to do it your way you should become the director and make it that way. You'll be sorry, but that'll be on your head.
I'm not sure if that's possible, but I haven't checked.
canucklady|3 years ago
singlow|3 years ago
deadbunny|3 years ago
epberry|3 years ago
There's one issue with companies using hundreds of AWS accounts if you're a vendor to them: integrating services. Some folks here may be interested in a technique called "CloudFormation StackSets" which can deploy bits of infrastructure to multiple AWS accounts in one command. Vantage uses this to setup our billing integration and we wrote up the method here, https://www.vantage.sh/blog/using-cloudformation-stacksets-t...
throwawaaarrgh|3 years ago
raffraffraff|3 years ago
... Like glauth? https://github.com/glauth/glauth
medina|3 years ago
rcrowley|3 years ago
albert_e|3 years ago
I should note that if you use AWS Control Tower Account Factory to create the member accounts then this role does not get created.
The "Audit" account that is created by Control Tower is probably the best one to serve as the Administrative Access Account
jeremya|3 years ago
This is an untrue statement. For a principal in the management account to assume OrganizationAccountAccessRole, they need to have a principal-based policy that gives sts:AssumeRole permissions for it. Otherwise, great article. We use this pattern at $DAYJOb
ManuelKiessling|3 years ago
benatkin|3 years ago
reilly3000|3 years ago
diceduckmonk|3 years ago
GCP’s IAM somewhat addresses the isolation and scope problem mentioned in the article. Not all GCP apis, atleast with respect to OAuth2, properly utilize IAM, insofar that they require overly power OAuth2 scopes. For example, to list cloud functions you need permissions to create and edit, too. That’s broken.
In GCP, many orgs find themselves proliferating in projects because GCP’s billing is abstruse. People isolate resources to projects so they know how much specific services actually cost. This in turn presents another problem. GCP Web Console’s search doesn’t index well. For example, substring search doesn’t work on far too many resources. VMs are the exception, but we think this is inverted. Substring search should work on every resource, not be exceptional. Historically it didn’t even do cross project search. This is frankly not acceptable for a search company.
rcrowley|3 years ago
judge2020|3 years ago
diceduckmonk|3 years ago
Disclaimer: we are building a search engine to search for resources across “workspaces”. In AWS, this unit is the Account. In GCP, this unit is the Project.
throwawaaarrgh|3 years ago
hatware|3 years ago
Hikikomori|3 years ago
1000+ accounts takes a few minutes.
manv1|3 years ago
pkrumins|3 years ago
jagged-chisel|3 years ago
gh0stcloud|3 years ago