Skip to content

Commit 83aec58

Browse files
0x2b3bfa00x2b3bfa0
authored
Merge branch 'master' into liason
2 parents 4816e2f + ba660a3 commit 83aec58

2 files changed

Lines changed: 113 additions & 2 deletions

File tree

‎documentation/aws-account-and-identity-architecture.md‎

Lines changed: 110 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,110 @@
1+
# AWS Account and Identity Architecture
2+
3+
This document describes the Helpful Engineering account and identity architecture for Amazon Web Services (AWS).
4+
5+
## Problem Statement
6+
7+
[Helpful Engineering](https://helpfulengineering.org) is creating and deploying applications to AWS as part of
8+
its mission to address the COVID-19 pandemic. These applications are needed or developed by project teams
9+
staffed by volunteers from all over the world.
10+
11+
The applications and project teams develop and operate independently, have limited time, and use a wide set of
12+
implementation technologies. Helpful Engineering has neither the time nor the staff to support high touch, high coordination
13+
solutions.
14+
15+
## Solution Benefits
16+
17+
Helpful Engineering needs an AWS account and identity architecture that maximizes data safety, team autonomy, and
18+
execution efficiency.
19+
20+
The solution should:
21+
22+
* Enable project delivery teams to deploy applications safely and independently.
23+
* Safeguard customer and organization data from external and internal threats, both accidental and malicious.
24+
* Minimize demand for scarce DevOps & Cloud skills.
25+
26+
## Key Use Cases
27+
28+
### UC1 - Deliver & Operate Applications Independently
29+
30+
HelpfulEng project teams and deployments are independent, do not generally depend on each other, and expect a high
31+
degree of autonomy. Project teams need to be able to develop applications, deliver them, and perform some amount of
32+
operational activities in a self-service, low coordination manner.
33+
34+
We anticipate that project teams will use a mix of manual and automated Cloud configuration and application deployment.
35+
Manual configurations are likely to be used in early prototyping and development. The DevOps team will enable and
36+
encourage automated configurations delivery and operation to production. The DevOps team has no plans to enforce that.
37+
38+
### UC2 - Provision Accounts
39+
40+
The HelpfulEng DevOps team will provision AWS accounts for both shared and project delivery accounts. The DevOps team
41+
would like provision these accounts in a standardized way with low effort and simple adoption of Cloud security and
42+
governance practices.
43+
44+
## Logical Architecture
45+
46+
This design provisions a set of AWS accounts for each project team to deliver their applications and a few shared
47+
accounts for prototyping, security, and governance. The Helpful Engineering AWS Organization will look like:
48+
49+
```
50+
HelpfulEng AWS Org
51+
└ Core
52+
└ Log
53+
└ Audit
54+
└ Sandboxes
55+
└ he-sandbox2
56+
└ Project Delivery
57+
└ Monitoring O2
58+
└ he-project-monitoring-O2-dev
59+
└ he-project-monitoring-O2-prod
60+
└ <project name>
61+
└ he-<project name>-dev
62+
└ he-<project name>-prod
63+
└ ...
64+
```
65+
66+
The design accommodates the wide set of people, skills, and techniques used throughout Helpful Engineering and scopes the
67+
management, fault, and security domain to the project team. Using separate AWS accounts for each project team
68+
creates a strong security boundary between teams that isolates each project's activities, resources, and
69+
data from each other.
70+
71+
The Helpful Engineering AWS Organization OU will be configured to match the depicted hierarchy. This OU
72+
structure enables use of both shared and project-specific Service Control Policy.
73+
74+
The DevOps team will use [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
75+
to provision both the shared and project accounts. Control Tower provides a simple account provisioning model that
76+
provides a number of security and governance best practices out of the box.
77+
78+
**Core Accounts**
79+
80+
The `Log` account contains the organization's API activity logs (CloudTrail) and resource configurations (Config).
81+
82+
The `Audit` account is a restricted account that gives security and compliance teams read and write access to all
83+
accounts in the landing zone.
84+
85+
**Sandbox Accounts**
86+
87+
The `he-sandbox2` account is a '[sandbox](https://chariotsolutions.com/blog/post/building-developer-sandboxes-on-aws/)'
88+
account teams can use to experiment and prototype solutions. Applications should not be operated for customers out of
89+
sandbox accounts. The DevOps team should consider enforcing this policy with a governance tool like Cloud Custodian
90+
that destroys resources some number of days after provisioning, e.g. 10 days.
91+
92+
**Project Delivery Accounts**
93+
94+
The DevOps team will provision two 'delivery' accounts for each project team: `dev` and `prod`. Teams will use the
95+
`dev` account to develop their applications and test application deployments. Applications should be delivered
96+
to the production account for operation and use by customers and end users.
97+
98+
The project team is responsible for delivering applications to their accounts with support by the DevOps team.
99+
100+
Project teams should adopt automated continuous integration to build application artifacts. These artifacts can be
101+
stored in:
102+
103+
* A trusted external repository such as Docker Hub.
104+
* An internal repository such as an S3 bucket hosted within a project account as is the case for the Serverless Framework.
105+
106+
The DevOps team recommends that project teams adopt automated continuous delivery to deploy and configure applications.
107+
108+
## Resources
109+
110+
* [How Should I Organize My AWS Accounts](https://nodramadevops.com/2019/01/how-should-i-organize-my-aws-accounts/)

‎documentation/directory.md‎

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -35,10 +35,11 @@ Each project keeps its own team directory [inside its main repository](https://g
3535
| [Jeremy Bass](https://app.slack.com/team/U010H4XVBML) | Azure ||
3636
| [Owen](https://app.slack.com/team/U0100NN6CS1) | AWS (specialize in Lambda), Python ||
3737
| [Peter](https://app.slack.com/team/U010AK510F2) | AWS | already working with [#project-user-database](https://helpfulengineering.slack.com/archives/C010GTD5US0) and [#project-hospitals-in-need](https://helpfulengineering.slack.com/archives/C010UK6GQPR) |
38-
| [Ramsey Sareth](https://app.slack.com/team/U010DLRQW0J) | AWS ||
38+
| [Rasmey Sareth](https://app.slack.com/team/U010DLRQW0J) | AWS, terraform, docker, python ||
3939
| [Rebecca Johns](https://app.slack.com/team/U0108S72KL4) | docker, K8s, AWS/GCP/Azure, sysadmin ||
40-
| [Shelia Loekito](https://app.slack.com/team/U010M0PL71R) | AWS, Go, Python ||
40+
| [Sheila Loekito](https://helpfulengineering.slack.com/archives/D010M0PM29H) | AWS, Go, Python, backend development ||
4141
| [Sri](https://app.slack.com/team/U010VVB2CVB) | AWS, Terraform/Terragrunt, Vault ||
4242
| [Uwe Janner](https://app.slack.com/team/U010JJGPQ7K) | Fullstack Java/JS/Node/Angular, AWS | also has technical project manager experience |
4343
| [Vineeth Soma](https://app.slack.com/team/U0111QFRE0N) | Arch review, AWS ||
4444
| [William Riley-Land](https://app.slack.com/team/U0107N17B0D) | node backend, react, AWS (CloudFormation in particular) ||
45+
| [Mitul Savani](https://app.slack.com/team/U01122NCA1L) | GCP ||

0 commit comments

Comments
 (0)