Investigate L7 packet inspection via packet mirroring all or filtered - to IDS, PaloAlto or Fortigate NGFW appliances

I'll verify the 25 peering limit for PSA as part of IDS (As apposed to PSC - slide 38 of https://docs.google.com/presentation/d/13sjT2tJ4yLIYGRREE3wBrylB1OvcEMpKdquVuJB_nX4/edit?resourcekey=0-N3DruQaiutFvZ98HTT7-vQ#slide=id.g1154b3b950f_2_4785)
https://cloud.google.com/vpc/docs/private-services-access
"Note: Because a private connection is implemented as a VPC Network Peering connection, the behaviors and constraints of peering connections also apply to private connections, such as VPC Network Peering limits."

15 May 2023: Update
- revisit the following issues
- close off the architectural use of IDS in option C of the network-patterns deck (public share here - slide 33 hybrid connectivity using appliances (shared VPCs in hub) https://docs.google.com/presentation/d/13sjT2tJ4yLIYGRREE3wBrylB1OvcEMpKdquVuJB_nX4/edit?resourcekey=0-N3DruQaiutFvZ98HTT7-vQ#slide=id.g1154b3b950f_2_3909
- benefits of the IDS managed NGFW cluster over other NGFWs that include inline IPS (Intrusion Prevention Systems) and also just Armor for enforcement/IPS
- FinOps at a base of $2/h for IDS and $1/hr for armor

LZ arch
- A1: The architecture of the managed LZ is multi-tenant - separate sets of dev/stg/prod per managed client - up to 40+
- A2: Keep all deployment artifacts in KCC using native GCP services. It would be ideal if we could utilize the IDS/Armor pair. We need justification and answers to implementation questions below.
- A3: Can we deploy with just require inline Armor without the compliance/governance/auditing capability of IDS

- The architecture direction we are in - option C (hub with NGFW multi-nic), our secondary option is B (separate VPC peers)
Option 2 of the architecture section
- https://cloud.google.com/architecture/landing-zones/decide-network-design#option-2
- which is Option C slide 33 in the deck
- https://docs.google.com/presentation/d/13sjT2tJ4yLIYGRREE3wBrylB1OvcEMpKdquVuJB_nX4/edit?resourcekey=0-N3DruQaiutFvZ98HTT7-vQ#slide=id.g1154b3b950f_2_3909
- NATing for CIDR overlap both only in GCP and across prem is also a design issue we are working out
https://cloud.google.com/architecture/deploying-nat-gateways-in-a-hub-and-spoke-architecture-using-vpc-network-peering-and-routing?hl=en

Specific questions are
- Q1 - Cost minimization - the goal is to use one cluster to avoid the $2.04/hr rising to <200k/year per client - we can reduce this to just classified/Cloud-Ground connections
- Q2 - We need the same functionality that inline NGFW's offer through the LB sandwich where we can use a central hub project for packet inspection through VPC peering (up to 25 clients - minus the IDS peer)
- Q2.1 - using a single managed IDS cluster in hub project (aka transit gateway) - as apposed to running separate IDS clusters per non-hub client projects.
- Q2.2 - Tradeoffs using Option C (hub multi-nic NGFW) or Option B (peering only)
For Q2 reference the LB sandwich pattern at https://github.com/fortinet/fortigate-tutorial-gcp#architecture
and some discussion about it in https://github.com/GoogleCloudPlatform/pubsec-declarative-toolkit/blob/dev/solutions/landing-zone/architecture.md#di-24-validate-vdom---virtual-domain-fortigate-zone-isolation
- Q4 - what benefits beyond packet inspection/alerting does IDS give over enforcement provided by managed Armor (which would be half the cost - plus rules over 100) coming in at half the cost of IDS alone
- Q9 - NGFW L7 packet filtering is required for a subset of environments (cloud profile 4-6 usually) - so feature parity is an aspect

References
- https://cloud.google.com/intrusion-detection-system
- https://cloud.google.com/armor

22 Nov 2022:
Determine applicability in terms of real time or near real time policy alerting, web filtering for both classified and unclassified workload traffic.

https://cloud.google.com/vpc/docs/packet-mirroring

Q: real time packet inspection/blocking - not just packet mirroring with detection/alerting?
Yes in IDS with static routes
https://cloud.google.com/blog/products/networking/using-packet-mirroring-with-ids