If we all started using Control Tower perhaps they'd get funded enough to continue to build it out and make it awesome.
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.
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.
For context, https://www.linkedin.com/in/richarddcrowley indicates he works there.
When customers request single tenancy in the cloud, where single tenancy is referring to an AWS account, being able to automate account management will be important when trying to scale.
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.
ControlTower for example. Takes about 30 mins to setup on normal AWS (on GovCloud it was much more complicated, took me half a day). But then setting up new accounts is one click and it’s preconfigured with correct restrictions and security measures, which individually would take several hours per account to do without controltower. So it’s an easy savings from the beginning. The only real cost is the cost of AWS config. So if you’re using that already (for SecurityHub for example) then it’s nothing additional.
IAM Identity Center makes user management not only more secure but faster and easier. It will take half a day to maybe a full day to setup the first time. But now every new user will be a few clicks with access across multiple AWS accounts. You can remove them in one click across all accounts. So these are just really simple additions to your workflow that save you time and improve security.
SSM is another example. It’s adding a policy to your instance role and checking a box (or adding a flag in Terraform or CLI) and it’s enabled. It’s no additional cost. It saves you time because you don’t need to manage user accounts on the server anymore (they are managed broadly through IAM or PermissionSets). No more copying around SSH keys or rotating them when people leave. It improves security and saves you time.
There’s little (if any at all) downside to any of these things. It’s all upside. For the most part, these don’t even have any significant costs associated with them. They are generally provided for free where you’re only cost is the underlying resources that you’re managing, which of course your paying for regardless.
https://medium.com/@unruly_mood/aws-ssm-sessions-root-non-ro...
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.
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.
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...
... Like glauth? https://github.com/glauth/glauth
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
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
It's the same in AWS with AWS SSO/IAM Center. You only login once, and you can access every other account (project) you're allowed to access.
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.
Do you have a concrete example of that? Or, maybe you mean the console needs those perms to work?
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.
You just blew my mind. We have two accounts and it gets messy sometimes.
1000+ accounts takes a few minutes.
They’re great, check them out.
We couldn’t build from source the last time we tried, but it is open source. We just made a decision today to open source our UI, so let us know if you’re interested
