Skip to main content

AWS Transit Gateway

Scope​

Note

Wayfinder does not manage the transit gateway configuration. Our goal is to remove the friction points in wiring networks together. Please consult the transit gateway documentation for details.

This topic provides an example for configuring your network to attach via AWS transit gateway.

Requirements for this example​

Let's assume you have these requirements:

  • All networks built into a development (nonprod) stage are peered with the transit gateway.
  • Limit the scope of the rule to only two workspaces.
  • You will scope which network blocks should route from source to transit gateway.
  • Use an externally managed AWS transit gateway that is shared within an organization or account.
  • You may or may not have permissions to automatically approve attachments into the transit gateway. This is optional–the transit gateway already comes with an auto-approval mode. If you want to be more selective, you can grant Wayfinder the permissions to approve only the networks it manages.

Network topology​


AWS Transit Gateway Network Topology

Peering definition​

This peering rule definition can be used to meet the above requirements.


note

You can also define and manage peering rules in Wayfinder's web interface.


---
apiVersion: networking.appvia.io/v1alpha1
kind: PeeringRule
metadata:
  name: transit
spec:
  # Filter down which network we are interested in
  filters:
    allocation:
      type: workspaces
      # Limit the scope of the rule to just these workspaces
      workspaces:
        - projecta
        - projectb
    selectors:
      # Limit the scope to only networks under the nonprod stage
      matchExpressions:
        - key: appvia.io/stage
          operator: In
          values: [nonprod]

  # Optional: if you would like Wayfinder to automatically accept the vpc attachments
  # on the transit gateway, this will require a cloud account with permissions.
  cloudAccount:
    # namespace for the credential (dont forget the ws-prefix)
    namespace: ws-admin
    # name of the cloud account
    name: management

  # Defines the details for the transit gateway
  connection:
    type: gateway
    gateway:
      # the transit gateway identifier
      identifier: tgw-0214f5342d763845f
      # indicates if we want to accept attachment requests
      enableAutoApproval: true
      # the routes we should push via the transit gateway
      routes:
        - 10.20.0.0/24
        - 10.200.0.0/22
      # provider specific details for aws only
      providerDetails:
        aws:
          # defaults to true
          enableDNS: true
          # defaults to false
          enableIPV6: false

You can check the status of the peering connections created from the rule using the CLI command wf get peering. For more information, see Peering Resources.

Note

Wayfinder's control plane runs within its own NetworkFabric, and is subject to the same peering rules. This is especially useful if the Wayfinder instance is connecting to private clusters via the transit gateway. See below for an example.

Attachment to the Wayfinder management network​

To give an example peering definition for attachment to the Wayfinder management network, let's introduce some new requirements:

  • You are provisioning private clusters with Wayfinder environments.
  • You want to use the transit gateway to act as the default route to the provisioned clusters.
  • You want to wire up the management network to the transit gateway.

You can find the Wayfinder management cluster network in the admin workspace (run: wf get networkfabric -w admin).

---
apiVersion: networking.appvia.io/v1alpha1
kind: PeeringRule
metadata:
  name: transit
spec:
  filters:
    allocation:
      type: workspaces
      workspaces:
        - admin
    selectors:
      matchExpressions:
        - key: name
          operator: In
          values: [management]
  connection:
    type: gateway
    gateway:
      # the transit gateway identifier
      identifier: tgw-0214f5342d763845f
      # indicates attachments must be accepted outside of wayfinder
      enableAutoApproval: false
      # we want to route all traffic down the tunnel
      routes:
        - 10.0.0.0/8

Auto approval​

Auto approval of VPC attachment is enabled in enableAutoApproval: true/false in the peering definition for transit gateway (see the above example).

Permissions for Auto Approval​

You can get the permissions needed for auto approval in two ways:

  • If the transit gateway is seated in the same account as Wayfinder, you don't need to do anything. Wayfinder always comes shipped with a NetworkManager role, which is scoped with correct permissions for the actions below. See this cloud account definition for an example.

    Statement:
      - Action:
        - ec2:AcceptTransitGatewayVpcAttachment
        - ec2:DeleteTransitGatewayVpcAttachment
        - ec2:DescribeTransitGatewayVpcAttachments
      Effect: Allow
      Resource: "*"

  • If the transit gateway is located in a different account than Wayfinder, you must create a cloud account with permissions to perform the above actions.

If auto approval is disabled in transit gateway​

If auto approval is disabled in transit gateway (for example if you configured it outside Wayfinder), what follows depends on the definition of Wayfinder's transit gateway peering rule:

  • If enableAutoApproval is set to true, Wayfinder waits for attachment and peering to be established.

  • If enableAutoApproval is set to false, Wayfinder indicates that action is required from the user, and falls into a holding pattern, waiting for an out-of-band acceptance to occur.

Last updated