search

org-formation / org-formation-cli

Better than landingzones!
MIT License
1.4k stars 129 forks source link

Enabling non-default regions #292

Open NickDarvey opened 2 years ago

NickDarvey commented 2 years ago

Subject of the issue

(This is likely a feature request because I think the currently suggested method of allowing specific regions in org-formation works a little differently to what I'm looking for here.)

I have an org-formation definition almost identical to org-formation-reference. I'm trying to enable af-south-1 which is not enabled by default (by AWS) and I'd like to do so by updating the allRegions parameter.

To enable one of these regions by console, I need to go to the account page and tap 'enable' next to the region, then go to IAM page and set STS region compatibility and change it from 'Only valid in AWS Regions enabled by default' to 'Valid in all AWS Regions' (or use the regional endpoints for STS).

See also https://github.com/org-formation/aws-resource-providers/issues/97.

Your environment

Steps to reproduce

  1. Set up https://github.com/org-formation/org-formation-reference
  2. Add af-south-1 to the allRegions parameter.
  3. Run deploy

Expected behaviour

  1. The AWS region is enabled on the/each account
  2. STS region compatibility is set to 'Valid in all AWS Regions'.

Actual behaviour

ERROR: Workload NoDefaultVpcRp in 1234/af-south-1 updated failed. reason: Account seems stuck initializing. (1234 = MyAccount)

Workaround

Go to each account and enable the region via the console.

Potential fixes

sshvetsov commented 1 year ago

I'm facing a similar issue when installing infrastructure in non-default regions with OFN.

Your environment

version of org-formation: 1.0.4 version of node: v16.15.1 which OS/distro: Ubuntu 22.04.1 LTS

Expected behaviour

OFN uses regional STS endpoints instead of the global endpoint.

Potential Fixes

Regarding potential fixes...

Org-formation uses account:EnableRegion IAM policies for allowing/denying regions. (Described here.)

Unfortunately, today AWS doesn't have APIs to enable non-default regions, meaning OFN cannot enable them. The IAM permission is there, but it only applies to changes made via the Accounts Console or via the Organizations Console (new feature). I've confirmed this point with AWS Support and raised a feature request for an API. Still, until AWS releases the API for enabling non-default regions, I don't think OFN can help.

Org-formation uses IAM API to enable 'all AWS regions' for the global STS endpoint. (CLI reference here.)

It's a good idea for folks who may choose to swtich to Version 2 of STS tokens and would want an IaC solution (e.g. a custom resource type Community::IAM::SecurityTokenServicePreferences) instead of manual CLI calls or console click-ops.

However, I feel that getting OFN to use regional STS endpoints by default is a more robust solution since it's what AWS recommends:

AWS recommends using Regional AWS STS endpoints instead of the global endpoint to reduce latency, build in redundancy, and increase session token validity.

OlafConijn commented 1 year ago

thanks for this!

i must admit i've never thoroughly read through benefits of using regional STS, but it seems indeed a step towards the right direction. happy to dive into this and look at how to integrate this into org-formation

sshvetsov commented 1 year ago

Thanks for considering this. I'd be happy to help test and provide any additional information. Feel free to ping me on Slack.

OlafConijn commented 1 year ago

great! so, i looked into this a little bit:

Using regional STS endpoints is something that could be added with relative ease without breaking backwards compatibility and allow for deployment to non-default enabled regions.

Looking at the services that would be instantiated I think there are only two that would need regional STS: CloudFormation & S3. tasks like CDK and serverless would have to rely on CDK and serverless to deploy to non-default regions (and/or regional sts).