fmichaelobrien
commented
1 year ago discussion around plugging in any type of NGFW
Open fmichaelobrien opened 2 years ago
fmichaelobrien
commented
1 year ago discussion around plugging in any type of NGFW
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
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
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