org-formation / org-formation-reference Goto Github PK

in order to

1. automate the installation of this reference architecture
2. integation with the org-formation-cli tool

I would be beneficial for this repo to support a formal templating language (e.g. Jinja).
The org-formation-cli can then use the repo-name as an option when performing init-pipeline in a similar way sls uses a --template-url (in our case maybe --template-repo?).

the replacement keys would need to be known in both the cli and this repo.

currently the tasks run 10 tasks x100 targets concurrently. yay!
i believe i have noticed concurrence issues with this. still needs investigation

I've followed the instructions until https://github.com/org-formation/org-formation-reference#5-initialize-org-formation and first it ran into a Error: Profile default not found error. I assumed I needed to put the root crendentials in, but that doesn't work:

(ins)hendry-tw-mbp~/orgtest/org-formation-reference$ npx org-formation update ./src/organization.yml --verbose
WARN: ======================================
WARN: Hi there!
WARN: You just ran into an error when assuming the role OrganizationFormationBuildAccessRole in account 381831929214.
WARN: Possibly, this is due a breaking change in org-formation v0.9.15.
WARN: From v0.9.15 onwards the org-formation cli will assume a role in every account it deploys tasks to.
WARN: This will make permission management and SCPs to deny / allow org-formation tasks easier.
WARN: More information: https://github.com/org-formation/org-formation-cli/tree/master/docs/0.9.15-permission-change.md
WARN: Thanks!
WARN: ======================================
ERROR: error: AccessDenied, aws-request-id: 018ac5f7-258a-4f88-aa23-76145560f36b
ERROR: Roles may not be assumed by root accounts.

And then I created a user with Administrator access rights and that also did not work:

(ins)hendry-tw-mbp~/orgtest/org-formation-reference$ vim .env 
(ins)hendry-tw-mbp~/orgtest/org-formation-reference$ source .env 
(ins)hendry-tw-mbp~/orgtest/org-formation-reference$ npx org-formation update ./src/organization.yml --verbose
WARN: ======================================
WARN: Hi there!
WARN: You just ran into an error when assuming the role OrganizationFormationBuildAccessRole in account 381831929214.
WARN: Possibly, this is due a breaking change in org-formation v0.9.15.
WARN: From v0.9.15 onwards the org-formation cli will assume a role in every account it deploys tasks to.
WARN: This will make permission management and SCPs to deny / allow org-formation tasks easier.
WARN: More information: https://github.com/org-formation/org-formation-cli/tree/master/docs/0.9.15-permission-change.md
WARN: Thanks!
WARN: ======================================
ERROR: error: AccessDenied, aws-request-id: 90d5db12-a048-4ffe-a999-73ad3c398472
ERROR: User: arn:aws:iam::381831929214:user/admintest is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::381831929214:role/OrganizationFormationBuildAccessRole
(ins)hendry-tw-mbp~/orgtest/org-formation-reference$ 

What am I missing please?

Hi there.

I am trying to follow the step by step instructions in the Readme, but unfortunately, I get an error when trying to configure the groups for SSO:

Any ideas?

would be great to have the OrganizationFormationInitialCommit task download the initial commit from a central repo. this will require an issue to be made over at org-formation-cli to allow for https:// or s3:// sources?

consider to change attributes to SourcePath/TargetPath?

OrganizationFormationInitialCommit:
  Type: copy-to-s3
  DependsOn: OrganizationFormationBuckets
  LocalPath: 'initial-commit.zip'
  RemotePath: !Sub 's3://organization-formation-deployments-${accountId}-prd/initial-commit.zip'
  OrganizationBinding:
    Account: !Ref accountId
    Region: !Ref primaryRegion

It would be nice to setup something like pre-commit so that we can setup multiple linters to validate files on every commit. It looks like there's lint-staged for the node environment. here's an example, https://juliangaramendy.dev/blog/prettier-pre-commit-hook

It's good practice to separate build pipelines and repositories to small units, while limiting the amount of dependencies. This enables different groups of ppl (teams) to work more independently of each other.

The prescribed way of org-formation of doing this is to use delegated builds. Might as well add a delegated build (repo and pipeline) into the reference architecture so users of the reference architecture have a starting point and example of how to set up a delegated build.

This could initially be done within the same OrgBuild account, with documentation of how to set it up in other accounts and guidance on whether or not to creating delegated builds within delegated builds is a good idea

currently 080-aws-config-inventory contains a ConfigTopic. if i understand correctly, this is a Topic that will be deployed to all accounts and can be used to subscribe Config Findings (or is it inventory delivery??).

either case:

• if config findings -> this should be in the security account (not all accounts) and not be part of the baseline reference.
• if inventory delivery -> i would leave it out of the reference arch.

move artficats buckets name to toplevel _parameters and reuse the artifcts bucket when deploying things like the guard-duty trusted-ips.

I think setting up and configuration of the AWS transit gateway is similar to AWS cloudtrail, guardduty and config. It's one of those resources that requires lots of cross account orchestration. It would be super helpful if this reference project contained an example of setting up the transit gateway in a multi account configuration.

would be good to have the notifications set up as: Budget -> SNS -> Email.
reason is twofold:

• more flexible
• budget fails on update resource if the Address attribute changes

i noticed that 060-cloudtrails has a binding for the S3 bucket called StorageBinding. 070-guard-duty calls this an ArchiveBinding. should this be harmonized?

OrgPipelineRole should be able to do with less permissions.

The permissions assigned are the default permissions for a CodePipeline as created by AWS (IIRC).
Could be a valid decision to leave as is so that other common pipeline stages can be added.
If so: add a link to this issue as a means to document?

would be most convenient to deploy the reference architecture using the Serverless Application Repository (from within the management account).

Limitations in CloudFormation would prevent you from executing code (cant do: org-formation init)... but if you do something like set up a codecommit/codebuild/codepipeline, point it at an 'initial-commit.zip' it will run automatically.

this is a bit of a hack but imho really worth the while.

implementing this reference architecture would then be as easy as:

1. create account
2. deploy using SAR
3. done

As per: https://twitter.com/awscloud/status/1374525809021566976?lang=en
The default branch on new CodeCommit repo's is now "main".

The reference to "refs/heads/master" in "/src/templates/000-org-build/build.yml//OrgBuildProject" should be updated to "refs/heads/main" to reflect this change.

The template here

Does not appear to match up with the use of the Community::Organizations::Policy

The following error will be the result

ERROR: Resource Scp failed because Properties validation failed for resource Scp with message:
#: required key [Content] not found
#: extraneous key [PolicyDocument] is not permitted.

When doing the integration of the secure defaults, I am getting the following error message on the register types I am integrating:

ERROR: Workload EbsEncryptionDefaultsRP in 123456789021/us-east-2 updated failed. reason: Error validating schemaHandlerPackage. Check the permissions on the bucket and object in your account and try again. (123456789021 = LogArchiveAccount)

This happens with the types that I am integrating, which are:

• EbsEncryptionDefaultsRP
• S3PublicAccessBlockRP
• NoDefaultVpcRP

I am doing the integration according to the reference. Additionally I was checking the providers (which seems to be a bit outdated) and I don't see anything different.

Am I missing something?

Currenlty we have a ComplianceAccount in the repo.
this account will, however, host two different types of resources:

• log archival for Config, CloudTrail, etc.
• the delegated administration controls for GuardDuty, SecurityHub.

I would propose to split this in two:

• LogArchiveAccount for log archival. Access would be very incidental, any access to this account could break glass.
• SecurityAccount for it-sec and compliance tools. Access would be part of a security officers day-to-day routine

I would like to suggest to add the NoDefaultVpc resource to the secure default.
The reason should probably be explained in the readme: the fewer resources you have in your AWS the less you have to worry about from a security perspective.

Only possible downside: it might break the build if the default vpc is in use. should we then add failuretolerance for this task?

behavior:

• new accounts -> default vpc gets removed from all regions
• existing accounts -> default vpc gets removed if not in use. when in use build logs errors and continues

Hi,

I'm hoping someone can help me. I'm running into an issue where I can't create the SCP to block regions, when it runs it looks like:

INFO: Executing: update-stacks templates/010-scps/deny-unsupported-regions.yml monad-deny-unsupported-regions.{"result":{"state":"FAILURE","reason":{"$metadata":{"httpStatusCode":200,"requestId":"1abcd8fa-5dd8-4340-8106-1ea449e194f6","attempts":
1,"totalRetryDelay":0},"Stacks":[{"StackId":"arn:aws:cloudformation:us-east-1:637423365128:stack/monad-deny-unsupported-regions/8060052
0-d0f7-11ee-9b0b-0e4b40acefbf","StackName":"monad-deny-unsupported-regions","Parameters":[{"ParameterKey":"targetIds","ParameterValue":
"r-yjlu"},{"ParameterKey":"supportedRegions","ParameterValue":"us-west-1,us-west-2,us-east-1,us-east-2"}],"CreationTime":"2024-02-21T20
:26:32.467Z","DeletionTime":"2024-02-21T20:26:37.173Z","RollbackConfiguration":{},"StackStatus":"ROLLBACK_COMPLETE","DisableRollback":f
alse,"NotificationARNs":[],"Capabilities":["CAPABILITY_NAMED_IAM","CAPABILITY_IAM","CAPABILITY_AUTO_EXPAND"],"Tags":[],"EnableTerminati
onProtection":false,"DriftInformation":{"StackDriftStatus":"NOT_CHECKED"}}]}}} (637423365128 = ManagementAccount)
ERROR: Resource Scp failed because Internal Failure.

I see the same thing in the console, with a failure and:

The following resource(s) failed to create: [Scp]. Rollback requested by user.

I tried looking through CloudTrail but I see nothing useful in there. I then tried making an SCP by hand (well, the policy) with the same regions just to make sure there wasn't anything obvious. That worked.

The params for this template look like:

supportedRegions: us-west-1,us-west-2,us-east-1,us-east-2
targetIds: r-yjlu

My manually created SCP was just the policy part, I didn't try to attach it to the target. Not sure if that's part of the issue. I'm not really sure what to troubleshoot next, I'm feeling a bit lost on this one!

I noticed that this repo follows the pattern that organization bindings are done at the task level, but the examples in the org-formation-cli repo seem to do it at the template level.

Are there trade-offs I need to consider about doing it in one place over the other?

For context, I'm about to follow the subdomains example to add a templates/120-dns folder and generate hosted zones for some accounts in my organization.

Did not see a discussion board, but I needed to complete step 3, before I could complete step 2. The reason for this is that you can not assume a role before the role is created.

would be great to move the !GetAtt AWSAccount.Tags.xxx expressions to the tasks file for better visibility, just like was done with 040-budgets

readme's need to be added to every folder

currently 050 is called event-routing. the contents is a sample on further automating the account creation process. i wouldn't look for that example within this folder.

should we rename to 050-account-creation?

Would be good to not set the Community::S3::PublicAccessBlock for some accounts.
Maybe implement this by adding a allow-public-buckets tag on the account resources?
this to avoid a surprise by which open s3 buckets are blocked

Step 5 of the README says that:

In this step, you run OrgFormation locally using the credentials of the root user of the management account

however running the update command gives me this result:

> org-formation update ./src/organization.yml --verbose "--profile" "dangerous"

WARN: Hi there!
WARN: You just ran into an error when assuming the role OrganizationFormationBuildAccessRole in account x.
WARN: Possibly, this is due a breaking change in org-formation v0.9.15.
WARN: From v0.9.15 onwards the org-formation cli will assume a role in every account it deploys tasks to.
WARN: This will make permission management and SCPs to deny / allow org-formation tasks easier.
WARN: More information: https://github.com/org-formation/org-formation-cli/tree/master/docs/0.9.15-permission-change.md
WARN: Thanks!
WARN: ======================================
ERROR: error: AccessDenied, aws-request-id: x
ERROR: Roles may not be assumed by root accounts.

(I think the warning is irrelevant in this case.)

I believe I could workaround this by creating an IAM account and specifying it as one of the assumeRolePrincipals for the next step:

aws cloudformation create-stack --stack-name org-formation-role --template-body file://src/templates/000-org-build/role.yml

Is this what I should be doing? Or have I likely got something else wrong?