(aws-networkfirewall): L2 construct(s)

[Obirah]

Description

Currently, there only are generated L1 constructs for the relatively new AWS Network Firewall service. The deployment of a network firewall with corresponding routing through several subnets is a bit cumbersome with those constructs and could heavily benefit from sophisticated L2 constructs.

Use Case

The approaches how one can/should deploy a network firewall are structured clear as can be seen in this AWS workshop.

However, with the L1 constructs one has to go "all the way" and implement all the bits and pieces of the architecture. This requires to write boilerplate code in several places. The most annoying one being the retrieval of the network firewall's VPC endpoint IDs.

I solved this problem with an AwsCustomResource looking somewhat like this:

    private createVpcEndpointProvider(): void {
        const describeFirewall: AwsSdkCall = {
            service: 'NetworkFirewall',
            action: 'describeFirewall',
            parameters: {
                'FirewallName': NetworkFirewall.FIREWALL_NAME
            },
            outputPaths: this.stack.vpc.availabilityZones.map(az => NetworkFirewall.vpcEndpointIdResponsePath(az)),
            physicalResourceId: PhysicalResourceId.of(`VpcEndpointIds`)
        };

        this.vpcEndpointIdProvider = new AwsCustomResource(this, `VpcEndpointIdProvider`, {
            onCreate: describeFirewall,
            onUpdate: describeFirewall,
            policy: AwsCustomResourcePolicy.fromSdkCalls({ resources: AwsCustomResourcePolicy.ANY_RESOURCE })
        });

        this.vpcEndpointIdProvider.node.addDependency(this.firewall);
    }

This seems like a recurring use-case that shouldn't require the user to write boilerplate.

Another use-case for L2 constructs would be the decoupling of the firewall policy and rule groups. Currently (to my knowledge) all rule groups must be specified inline in the properties of CfnFirewallPolicy. It would be nice to be able to add more rule groups to an existing firewall policy from other stacks.

Proposed Solution

Implement L2 constructs for the network firewall entities, that...

• ...make the VPC endpoint IDs directly accessible
• ...additionally provide the option to automatically deploy parts of the infrastructure that are required to implement the centralized or decentralized models of the network firewall
  • example: creating a NetworkFirewall L2 constructs allows the user to automatically deploy a firewall subnet for each AZ and to automatically create the Firewall policy
• ...provide APIs to manage firewall policies in a decoupled way
  • example: make the firewall policy importable through something like FirewallPolicy.fromFirewallPolicyArn(...) so that one can add more rule groups to an existing firewall policy from another stack
• ...provide abstraction for firewall rule groups
  • example: a stateful rule group for domain allow- or deny-lists always looks pretty similar. It would be cool to have something like a DomainAllowList and DomainDenyList class that wraps all the recurring code.

This is just a loose collection of ideas. I'm sure there's more that can be done, so feel free to add more ideas.

Other information

No response

Acknowledge

• I may be able to implement this feature request
• This feature might incur a breaking change

[github-actions]

This issue has not received any attention in 1 year. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.