The GCP PubSec Declarative Toolkit is a collection of declarative solutions to help you on your Journey to Google Cloud. Solutions are designed using Config Connector and deployed using Config Controller.
Apache License 2.0
32
stars
28
forks
source link
Compliance: ITSG-22 Network Security Zones and ITSG-38 Network Security Zoning - Design Considerations for Placement of Services #78
20220920
Network separation question:
We have a couple options to start -
1 - shared VPC (host) - with service subnets - this works best for PaaS workloads (with some sharing - where separation is at the k8s namespace and/or service level) - (aka transit gateway)
2 - workload (non-shared) VPC's peered to the shared perimeter (1 fortigate cluster per gc-cap - with flow separation)
3 - workload (non-shared) VPC's peered to their own perimeter (usually prod/stg/dev fortigate separation but we can expand) - I have only see 2 above though
For all 1-3 we can separate using explicit and implicit routing/firewall-rules separation
Usually 2-3 are for both free-form sandbox and specific prod workloads (one team does bucket downloads for example) - where the rest of the workloads are ok with sharing the paas in 1
We have been focused on ITSG-33 security controls until 202208 - we need to verify our compliance with Network Zoning and ZIPs (Zone Interface Point)
ITSG-22 https://cyber.gc.ca/en/guidance/baseline-security-requirements-network-security-zones-version-20-itsp80022 and https://cyber.gc.ca/sites/default/files/cyber/publications/itsp80022-e.pdf
ITSG-38 Placement of Services with Zones - https://open.canada.ca/data/en/dataset/7ef76a62-bb53-4e9c-b2a4-03e5c53570a1 and https://cyber.gc.ca/en/guidance/network-security-zoning-design-considerations-placement-services-within-zones-itsg-38 SSC 2020 https://wiki.gccollab.ca/images/9/9d/Network_Security_Zoning_Reference_Architecture.pdf
Flows, firewall demarcation, encryption in transit levels l3/l4 (default internal) + l7
Expand on https://cloud.google.com/architecture/landing-zones/decide-network-design#option-2 in https://cloud.google.com/architecture/landing-zones#what-is-a-google-cloud-landing-zone
Google Front End Service (reverse proxy) - https://cloud.google.com/docs/security/infrastructure/design#google_front_end_service
20220920 Network separation question: We have a couple options to start - 1 - shared VPC (host) - with service subnets - this works best for PaaS workloads (with some sharing - where separation is at the k8s namespace and/or service level) - (aka transit gateway) 2 - workload (non-shared) VPC's peered to the shared perimeter (1 fortigate cluster per gc-cap - with flow separation) 3 - workload (non-shared) VPC's peered to their own perimeter (usually prod/stg/dev fortigate separation but we can expand) - I have only see 2 above though For all 1-3 we can separate using explicit and implicit routing/firewall-rules separation Usually 2-3 are for both free-form sandbox and specific prod workloads (one team does bucket downloads for example) - where the rest of the workloads are ok with sharing the paas in 1
see prototyping that needs to be moved to kcc org a- gcp.obrien.services https://console.cloud.google.com/networking/peering/list?orgonly=true&project=ospe-obs-obsprd-obspubper&supportedpurview=project
Existing peering to be updated as per https://github.com/GoogleCloudPlatform/pubsec-declarative-toolkit/blob/dev/solutions/landing-zone/architecture.md#di-20-separate-vpc-per-cloud-profile-356-workloads
uncomment and KPT render each peer pair in https://github.com/GoogleCloudPlatform/pubsec-declarative-toolkit/blob/main/solutions/landing-zone/environments/common/network/network-peering.yaml#L15