Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create transit gateway composition #3596

Closed
Tracked by #3469
mproffitt opened this issue Jul 24, 2024 · 3 comments
Closed
Tracked by #3469

Create transit gateway composition #3596

mproffitt opened this issue Jul 24, 2024 · 3 comments
Assignees
Labels
team/honeybadger Team Honey Badger

Comments

@mproffitt
Copy link

mproffitt commented Jul 24, 2024

It has been identified that there is the need for a transit gateway between the management cluster VPC and infrastructure VPCs

This needs to be added as a new composition that can be nested inside the VPC composition to create a transit gateway that can optionally connect between transit gateways to enable hub-spoke models.

@mproffitt mproffitt self-assigned this Jul 24, 2024
@architectbot architectbot added the team/honeybadger Team Honey Badger label Jul 24, 2024
@mproffitt
Copy link
Author

The main trunk composition is done and partially tested

Still missing:

  • TGW peerings - these need to be added in to enable hub/spoke
  • Managed Prefix lists - This really wants its own composition but is of less importance right now
  • Resource Access Manager - This is required to be able to cut cross account. The stubs are created but hasn't been enabled or tested, potentially needs to be moved into its own composition to be shared with the VPC network

@mproffitt
Copy link
Author

mproffitt commented Jul 31, 2024

Transit gateway peering has been added this morning however this requires the transit gateway to be aready connected to a VPC unless an ID is provided (no looking up by name)

In order to achieve true peer to peer transit gateways with name lookup, additional regional discovery needs to be carried out. This is outside of the scope of the network-discovery function which is designed to track VPC networks, not regional or global networks.

I think for the moment this is a fair compromise - to find by name, the TGW must be attached to a VPC, otherwise provide an ID.

The interface then becomes:

transitGateways:
  peers:
    name: ""              # required if ID is not provided
    id: ""                # optional, takes precedence over name
    accountId: ""         # optional falls back to VPC owner ID
    providerConfigRef: {} # Provider Config to use for this TGW 
                          # - falls back to composition providerConfig
    region: ""            # optional, falls back to composition region

@mproffitt
Copy link
Author

OK I think this is done. The transit gateway gets created, managed prefix lists are applied where relevant

I have not tested this in all configurations and still have to get data through it but for all intents and purposes, the gateway comes up, routes are added, MPLs are configured - there is nothing I can see that says this won't "just work™"

Anything outstanding can be covered under testing and bug-fixes 😌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team/honeybadger Team Honey Badger
Projects
Archived in project
Development

No branches or pull requests

2 participants