Organization & landing zone#

Caascad#

Organization structure in Caascad#

The following organization reflects the recommended AWS Landing zone, a blue print to manage multiple AWS accounts.

It distinguishes Core accounts from member accounts that are assigned to the Custom OUs.

Those member accounts are created with an "account factory".

Notes

Account aliases must be unique through AWS
Each AWS account needs a dedicated email adress
One AWS account per zone (kubernetes cluster) running on AWS. If no cluster, use caascad-dev or caascad-prod.
Each "member account" follows a baseline of preconfigured services :
- AWS CloudTrail
- AWS Config
- AWS IAM (roles and IDP)
- AWS SNS
- AWS GuardDuty

Used AWS services#

At the master account level:#

Organization
IAM
SCP
AWS SSO
Service Catalog
CloudFormation
CloudTrail
Firewall Manager
GuardDuty

At the member account level:#

CloudTrail
Config
IAM
SNS

Landing Zone bootstrap#

To ease the setup and the management of the Organization, AWS offers two possibilities :

Use Landing Zone - a set of cloudformation stack made by AWS solution architects
Use AWS Control Tower - an AWS service

A third possibility is to DIY (Terraform or Cloud Formation)

Because Control Tower can be deactivated without destroying accounts, it seems to be a good starter. Then wait and see to switch on a custom landing zone.

NGOT#

For NGOT we received a unique AWS account from AWS Orange Practice. To integrate it we filled it in Caascad zones as a non managed account.

Next steps#

Study integration of external IDP with AWS SSO in particular "the SAML protocol does not provide a way to query the IdP to learn about users and groups. Therefore, you must make AWS SSO aware of those users and groups by provisioning them into AWS SSO"
Define the target for the vault_aws backends:
- repartition vault / AWS account
- which roles for the types of vaults (corp, infra, cloud)
- cross-account access