Cloud Guardrail for Sandbox environment not clear

[PatrickMessierGoC]

Problem to solve

We are trying to understand the "segment & separate" requirement for "Experimentation/Sandbox" (profile 1) environment. We find the statement "Required (network filtering at a minimum)" is vague and open to interpretation.

Intended users

Departmental teams mendated to implement Cloud Guardrails.

Further details

Development teams request public cloud environment to implement DevOps workflows whereas IT Security teams often claim that, based on the "segment & separate" requirement, development environments must be behind firewall, thus be somewhat private, even if "Experimentation/Sandbox" environments is used.

Proposal

Can you please elaborate on what is truly expected from this expression and add those clarification to the table here. For example, would IP filtering on resources be enough for trully development enviroment?

Permissions and Security

N/A

What does success look like, and how can we measure that?

• Documentation is updated with more details and concrete examples of what is acceptable for the "Segment and separate" guardrail for "Experimentation/Sandbox" environment.
• Clarifications is added on which environment/profile is suitable for DevOps workflows.

Links / references

N/A

[fmichaelobrien]

Patrick, Thanks for the question - very good point - I have run into this myself gathering compliance evidence - yes GR 8 at the profile 1 level https://github.com/canada-ca/cloud-guardrails/blob/master/EN/00_Applicable-Scope.md usually involves the default VPC (non-shared at this point) with default ingress/egress FW rules, no policies, no org policies on public IP restriction.
However it is recommended to have GR 5 - regional restriction to the 2 regions in Canada - this will force VPC creation to limit to these 2 regions and provide for minimal segmentation.

Ideally a network diagram like the following would help but not required.

As a work item over the next couple days I will add a PR to adjust the scope of the GR8 ask in terms of detailing "Network Filtering" - which implies either a cloud native DDoS, Firewall, AV, WAF, IPS/IDS packet inspection set of services or NGFW appliance like Fortigate - or VPC network separation - which is - I think the intention of "Network filtering". In this case VPC separation via routes, FW rules at the VPC or tag level for IaaS VMs in the VPC) - all of which in the case of most CSPs including GCP are part of a default VPC (as long as regional restriction policy is in place)

Security Control
https://github.com/GoogleCloudPlatform/pbmm-on-gcp-onboarding/blob/main/docs/google-cloud-security-controls.md#iam---organization-policies---resource-location-restriction

Code:

Guardrails

• https://github.com/canada-ca/accelerators_accelerateurs-gcp/blob/main/deployment-templates/Terraform/guardrails/1-guardrails/org-policy.tf#L13

Kubernetes Config Controller Landing Zone

• https://github.com/GoogleCloudPlatform/pubsec-declarative-toolkit/blob/main/solutions/landing-zone/environments/common/guardrails-policies/05-data-location/constraint.yaml#L26

[PatrickMessierGoC]

@fmichaelobrien Thanks for your quick reply. Any ETA for the documentation updates?