Draft Cloud Resource Organization Hierarchy

[kj4ezj]

While working on Developer Relations issue 80, I found there is not currently an organized layout of organizational units (OUs) and accounts in Amazon Web Services (AWS). These terms correspond to folders and projects in Google Cloud Platform (GCP), respectively, and we likely don't have a strategy for organizing resources there either. I brought up this concern and was asked by @ericpassmore to come up with such a strategy. This ticket tracks that subset of work.

[kj4ezj]

I recommend reviewing the following relevant resources:

1. AWS Organizations Terminology and Concepts
2. Using Resource Hierarchy for Access Control
   • At least read the Best Practices section at the very bottom.
3. The first section, Why Should I Set Up a Multi-Account AWS Environment?, in Establishing Your Best Practice AWS Environment
4. Best Practices for the Management Account

I propose we use the same organization strategy regardless of cloud provider, for consistency. AWS and GCP "best practices" contradict in the sense that AWS recommends against using an organization structure that is similar to your reporting structure, whereas GCP recommends for doing this. Neither explain why they make that recommendation, and I didn't find useful discussions about this online. I align more with GCP in this regard. Note that the structure can be changed.

I recommend we adopt the following structure.

Here, AWS nomenclature is in black while GCP nomenclature is in blue. The solid lines are resources that I recommend creating immediately, whereas the dotted lines are resources we may want in the future. These are primarily included to help visualize how the hierarchy would be used as we grow.

We would have the following layers.

1. Organization Root
   • This layer is created by the cloud provider and is not optional
   • Only one root can exist in an organization
2. Business Unit
   • This layer divides resources at the highest level based on business strategy
   • One could imagine any of the nodes in this layer being bought, sold, spun off into a subsidiary, transferred to a parent company, or discontinued
   • The Meta organizational unit is an AWS-specific implementation detail which holds:
     • The management account Amazon requires us to have
     • A second account containing resources for administering the organization using roles assumed from the management account, because Amazon recommends against putting any cloud resources in the management account for security reasons
       • For example, if we defined our AWS organization in Terraform to provide traceability and protect it using revision control, peer-review and automated deployments, the Terraform state bucket could live here
   • The Admin organizational unit is just an example that might contain resources relevant to the administration of the entire organization, such as buckets for grant information
3. Department
   • Different internal ENF entities collaborating on a business unit would have their own resources
     • For example, engineering might have virtual machines for testing, while developer relations might be hosting documentation
     • IAM groups might be used to give departments Read access at this level
   • Another way to think about nodes at this level could be customers of a cloud infrastructure team for a given business unit
4. Environment
   • Engineers usually have multiple different deployments of the same system so they can test their changes without breaking customer-facing systems
     • For example sandbox, development, staging, production, bug bounty, cybersecurity, etc.
   • IAM groups may be used to grant all members of a team Write access to lower environments, and Read access to higher environments at this level
5. System
   • Each system or project would have its own account/project in relevant environments
6. Resources
   • Individual cloud resources such as buckets, virtual machines, databases, and Kubernetes clusters inside an account/project

What is not captured in the diagram above is that we should be making use of IAM groups (called Google groups on GCP) to make it easy to grant permissions to specific teams. This makes it easier to revoke permissions from a specific individual who leaves our organization because instead of editing all of the nodes in the hierarchy, an administrator would only have to edit the IAM group.

[tedcahalleos]

Thanks for doing this Zach. Per my comments of Antelope and ENV being parallel orgs, it would be good to update the picture. Also OK to add in a perf_harness account/org parallel to DevRel and Engineering. This is very helpful.

[stephenpdeos]

https://github.com/eosnetworkfoundation/product please submit PR in this repo for md file documentation

[kj4ezj]

I believe this is not practical to implement until issue 12 is addressed.