-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Case: POC Serverless Canary Application (frontend/backend/persistence) as a Profile 3 LZ workload with PSC, PSA and VPC-SC #418
Comments
Implementation |
Verify VPC-SC across 2 service projects in a shared VPCGoal/Requirements
Testing
VPC Service control zone must include both service projects
create vpc service control access policy at the org level grant uses to the shared subnets add projects to the perimeter add resources to the perimeter to protect Create VMs in subnets
create a bucket with files to be accessed both inside and outside the perimeter in the source-svc project Test access from ext-svc before/after perimeter is set
|
check VM access to bucket inside future perimeter
add the VM service account as reader visible
set VPC service perimeter around the bucket specific to the source service projectadd 2 projects to the perimeter add cloud storage to the perimeter checking - the reverse of what I expected - source is blocked, ext is not
however turning on ext on and off in the perimeter sets the VPC SC flag - but I cannot get it reset
delete perimeter but keep default policy - to reset
VPC-SC: There are additional ingress and VPC owning project inclusion attributes to VPC Service Control - Perimeters in the policy such as per vpc/perimeter. Triaging VPC-SC config using a gs bucket in the notes starting at #418 (comment) reference Missing the ingress rule and we also need the perimeter all the way around the host project as well - or else we use bridges after the ingress rule we have the proper internal gsutil usage and blocked external gsutil usage
|
202401 update
Use Cases
Serverless Reference Architecture
Requirements: LZ workload Canary for Profile 3
P3 specific - we run a selected subset of all packages (armor yes, IDS/NGFW perimeter and extensive hub/spoke - no) for example
a VPC Service Control egress perimeter is involved
VPC Serverless Connector
No NGFW for east-west traffic
Armor attached to an LB (off the GFE)
SWP - Secure Web Proxy
External Cloud Load Balancer - https://cloud.google.com/load-balancing/docs/https
Artifact Registry and cloud build pipelines will work with the vpc-sc
hierarchical firewall policies at the 5 org/folder/vpc/region levels
the ALB in cloud run is not the Global LB
cloud run will use either a SQL proxy or vpc connector for private IP based cloud SQL connections
Ideally Guardrails V2 over V1
https://github.com/canada-ca/cloud-guardrails-v2/tree/main/EN
https://github.com/canada-ca/cloud-guardrails/blob/master/EN/00_Applicable-Scope.md#applicability-of-guardrails-to-cloud-usage-profiles
Design
Reference
Implementation
Package Coverage Required
or
Package Coverage Optional
Design Issues
Template
Introduction
• Deliverables
• MVP - Immediate Minimum Viable Product
• Quickstart
• Artifacts
• Requirements
• Features
• Analysis
• API
• Architecture
• Use Cases
• Design
• Design Issues
• DevOps
• Deployment
• Testing
• Security
• Monitoring
• Releases
• Documentation
• Development Log
• Keywords
• References
• Links
reference as well https://github.com/ssc-spc-ccoe-cei/gcp-tier34-template
The text was updated successfully, but these errors were encountered: