Introducing New Design Blueprint Using Third Parties - Stage 1 Networking

[hassannmoussaa]

Idea Proposal

As the need for landing zone deployment on GCP is growing, and automation is always needed, and from the fact the using third parties from Google Partners are a must to fulfil the customer needs, new blueprint from the recommended designs by third parties become needed. From my experience at a Professional Services engineer at Google Premier Partner, we are requested every day to deploy hub-spoke models using third parties tools such as Palo Alto VM_Series , fortigate , f5 , ....

Based on the above mentioning, i would like to suggest ( and would love to work on this as contribution) to have new blueprint on the networking stage that introduce more dynamic and production-ready terraform templates and i'm listing down one of the suggestion that we can work om

Dedicated NVA - Third Party Hub & Spoke Model

As per palo alto and google official documentation which you can refer to using the links in the references, the recommended design for palo alto on gcp now become either having dedicated pair of VMs for inbound and outbound, or single pair of VMs for both direction, in my today issue im suggesting having a terraform ready blueprint that deploy the following production-ready hub-spoke dynamic model in the following design.

Architecture Explanation

The above design is a hub and spoke design based on a hub project that include a trusted and untrusted zone where traffic flow move from untrusted to trusted passing by load balancer with the first set of VM-Series ( Palo Alto) backend for inspection and threat detection.

Because hybrid connectivity is always a need, a VPC for VPN is needed, where this VPC is peered to the trusted and because transitive peering is not allowed this traffic will pass by the second set of vm-series for inspection

Outbound traffic initiating from the VMs are inspected by another set of palo alto to eliminate bandwidth issue and for better visibility.

Trusted VPC is peered with a set of prod and non prod shared VPCs that share their network with service project that contain the actual workload.

Proposed Work

I would like to contribute and to split the following issue and feature into multiple issues to make easier for maintainer to conduct the code review and validation.

In my proposal , i would suggest to work on something similar to the available blueprint in stage 2, where we can have a fully dynamic terraform model that deploy this well needed architecture on GCP following the design principles followed by fabric fast modules and following the same structure.

Next Steps

i would like to hear from this repository maintainer about this idea in order to agree on it, thus i have some ready modules that i can work on to match fabric fast design principles and contribute to the repository with this new design in order to have it ready in the next releases .

Moreover from the fact that issues are a way to introduce feature and issues should be simple and direct, i would like to split this feature into multiple smaller issues in next work in order to merge this change step by step

As a next step , I'm planning to involve other recommended designs such as :

• Shared set of palo alto hub and spoke model
• FortiGate recommended design

And other recommended design that we feel they are very requested nowadays in order to enrich current fabric fast foundation modules with more production-ready and user-needed designs and architecture

Conclusion

i would like to know more from this page maintainer about my thoughts and im always ready to help and contribute

[ludoo]

@sruffilli can you chime in here?

[hassannmoussaa]

Appreciate your thoughts, @sruffilli

[hassannmoussaa]

A gentle reminder

[sruffilli]

Will TAL by EOD :)

[sruffilli]

Hey @hassannmoussaa, thanks for kicking off the discussion.
While I understand and appreciate the need for additional blueprints implementing the reference designs for the different vendors, there's two main things I'm concerned about:

• The proliferation of networking stages is (already) a maintainability burden. Unfortunately every time a module updates its interface, or as we come up with a novel implementation (e.g. dns policies for PGA), 5 different network stages must be painstakingly updated and aligned with each other. Coming up with multiple new stages would only aggravate the problem.
• Lack of testability due to an explicit dependency to appliances requiring a license to be deployed. While this could be alleviated by deploying simple-nva placeholders, doing so would IMHO result in a futile exercise given a good 95% (100%?) of the rest of the infrastructure would be vendor agnostic.

A low hanging fruit could be adding additional VPCs (at least one for management and one for heartbeat, which is pretty common across vendors) to the existing 2-networking-c-nva.

Something that could be done on top of that would be re-architecting (as/if required) the current 2-networking-c-nva stage to parcel out everything that is related to NVAs to clearly identified nva-*.tf files, and implement (in a separate "3p-plugins" folder?) drop-in terraform files for vendor-specific solutions.

@ludoo @juliocc wdyt?

[hassannmoussaa]

@sruffilli

Thank you for your insightful response. While i totally agree with your mention, allow me to suggest some potential workaround from my side.

• While adding stages will be a maintenance nightmare, we can reduce changable features like dns,... into modules with default values, this could provide some facilitation to add more stages while editing the basic features from module default values.

• Im wondering if we can use a gcp free trial license (payg free trial) as testing material for almost all well-known NVA

• Editing basic model of NVA would be a great solution as the typical NVA deployment nowadays is using these 4 VPCs, moreover introducing a fully production-ready blueprint stages will empower end-user with architecture that i can see they are well implemented and requested today on GCP ( like 1 layer palo alto model , 3 layers fortigate -- F5 -- Palo Alto ) and so on

I would love to hear from all of you your thoughts while really intersted to contribute to what we could agree on.

🚀

[juliocc]

While adding stages will be a maintenance nightmare, we can reduce changable features like dns,... into modules with default values, this could provide some facilitation to add more stages while editing the basic features from module default values.

This will require calling modules within modules, which goes directly against our design principles.

Im wondering if we can use a gcp free trial license (payg free trial) as testing material for almost all well-known NVA

The problem is not about licensing/cost. We're talking about unit or e2e testing.

Something that could be done on top of that would be re-architecting (as/if required) the current 2-networking-c-nva stage to parcel out everything that is related to NVAs to clearly identified nva-*.tf files, and implement (in a separate "3p-plugins" folder?) drop-in terraform files for vendor-specific solutions.

I like the plugin idea but I'm not sure how far we can push it. If it works out, this would be a reasonable compromise IMO.

@hassannmoussaa What is your goal having this in the core Fabric/FAST repo? You could potentially host this network stage in a separate repo (and we could link your repo from the networking READMEs)

[hassannmoussaa]

@juliocc Thank you for mentioning this ,

From my basic experience, i can see that fabric fast is being used officially for deploying landing zone architecture proposed by the PSO team

While i can see that the customers today care about migrations and IAAS and still we are step behind the fully modernized architecture, security is a concern .

Basic on that, the customers are asking more for NVA that could secure Iaas as per the shared responsibility model.

Having it on the fabric fast could facilitate this mission for the system integrator. This could provide it more credibility.

While i can see this, This will add a layer of complexity over the basic designs and implementation.

[ludoo]

Plus one on the proposal to add the missing bits to the current nva stages, this is painless and actually pretty useful.

Encapsulating functionality specific to network stages is something we will never do, as we always strived very hard to reduce the number of layers.

[hassannmoussaa]

@ludoo Thank you for your clarification

So one thing is we can proceed to edit the current nva stage to include 4 VPCs and almost peering with shared VPCs , while we can make the number of NVA dynamic for dedicated inboud/outbound and HA options ( if you agree on this proposal )

Can you provide your thoughts on having a 3-plugin folder for deploying vendor specific NVA along with their basic configuration (HA , interfaces ,... ) , do you see that a good addition ? And how shall we consider it on this change

Thank you for your time

[hassannmoussaa]

@ludoo @juliocc @sruffilli

What about proceeding with the esit for the additional VPC in the nva stage and editing the documentation

While working on an external repository for deploying vendor specific deployment such as vm-series , fortigate,..

I have one question here , if we want to work on an external repo and the deployment model needs editing for vpc or require additional VPCs like having multiple NVA how we could manage that or that is not a requirement at the moment

Moreover, could we consider having peering with shared VPC for the current nva stage

Appreciate your thoughts

[sruffilli]

What about proceeding with the esit for the additional VPC in the nva stage and editing the documentation

Sounds good, go ahead and send a PR!

I have one question here , if we want to work on an external repo and the deployment model needs editing for vpc or require additional VPCs like having multiple NVA how we could manage that or that is not a requirement at the moment

I suspect all of that can be parceled out to those "plugins". But I guess it'll be much more clear as you'll start developing the first plugin.

Moreover, could we consider having peering with shared VPC for the current nva stage

Can you please give me more details here?

Thanks!

[hassannmoussaa]

@sruffilli i meant changing the type of the peered vpc in the initial design ( the two peered VPC) to shared VPC not normal VPC so other service project can consum network

Ill move forward with the agreed PR

Thank you

[hassannmoussaa]

@sruffilli @ludoo one more request, can you please share with me the architecture included in nva documentation as lucid chart document if that is possible

Appreciate it , below my email

hassannmoussaa@gmail.com

[sruffilli]

@sruffilli i meant changing the type of the peered vpc in the initial design ( the two peered VPC) to shared VPC not normal VPC so other service project can consum network

Ah sure

@sruffilli @ludoo one more request, can you please share with me the architecture included in nva documentation as lucid chart document if that is possible

You meant Google Slide :)? On its way.

[hassannmoussaa]

PR Opened

#2180