SkarpChapter 25 of 27
Network Security, Shared VPC, and Perimeter Controls
Locking down networks is as important as IAM; configure Shared VPCs, firewalls, and related controls to protect services without breaking connectivity.
Big Picture: Network Security on Google Cloud
Why Network Security Matters
Even with perfect IAM, a weak network can expose workloads. Network controls decide what can talk to what at runtime.
Key Building Blocks
You will work with VPCs, Shared VPC, firewall rules, and private access features to protect resources without breaking connectivity.
What You Will Learn
You will design Shared VPCs, apply least-privilege firewall rules, use private access patterns, compare isolation options, and troubleshoot issues.
VPC and Shared VPC Fundamentals
VPC Basics
A VPC is global, subnets are regional. VPCs use routes and firewall rules and are isolated by default until you connect them.
What Is Shared VPC?
Shared VPC lets a host project share its VPC with service projects. Service projects attach resources to host subnets.
Why Use Shared VPC?
It centralizes IP planning, routes, and firewalls, giving network/security teams control while app teams deploy resources.
Designing a Secure Shared VPC: Roles and Responsibilities
Who Owns What?
Host project admins own VPCs, subnets, and firewalls. Service project admins deploy resources into those shared subnets.
Shared VPC Design Patterns
Common patterns: one Shared VPC per environment (prod vs nonprod) or per business unit, each with its own host project.
Exam Signal
If a scenario needs centralized network control across many projects, Shared VPC with a host project is usually the right design.
Firewall Rules: Model, Priority, and Scope
Firewall Rule Basics
Each rule has direction (ingress/egress), action (allow/deny), priority, targets, and source/destination criteria.
How Rules Are Evaluated
Lower priority numbers are evaluated first. The first matching rule wins. An implicit deny-all applies if nothing matches.
Default Rules and Hardening
New VPCs have broad default allow rules. For secure environments, delete or tighten them and use specific, tagged rules.
Designing Least-Privilege Firewall Rules (with Exam Traps)
Scenario Setup
You have web servers (tag web) and databases (tag db) in a Shared VPC. Users need HTTPS to web, web needs DB access, DB must not be public.
Allow HTTPS to Web
Create an ingress rule targeting tag web, source 0.0.0.0/0, protocol tcp:443. This exposes only HTTPS externally.
Allow Web to DB, Deny Others
Create an ingress rule to tag db from tag web on tcp:5432, and optionally a higher-priority deny from 0.0.0.0/0 to db.
Private Google Access and Private Service Connect
Why Private Access?
When VMs have no external IPs, they still need to call Google APIs and services while keeping traffic private.
Private Google Access
Enable PGA on a subnet so VMs without external IPs can reach Google APIs using only internal IP addresses.
Private Service Connect
PSC creates private endpoints in your VPC to access Google or partner services without using public internet.
Perimeter and Isolation Patterns: Shared VPC vs Peering vs Separate VPCs
Separate VPCs
You can isolate dev, test, and prod in separate VPCs with no connectivity for strong separation and small blast radius.
VPC Peering
VPC peering links two VPCs for private IP traffic. It is non-transitive and each VPC keeps its own firewalls and routes.
Shared VPC Choice
Shared VPC centralizes one VPC across many projects. Choose it when you need centralized, consistent network controls.
Thought Exercise: Designing a Secure Shared VPC Layout
Use this scenario to practice design thinking.
Scenario:
A company has:
- A central networking team.
- Three application teams: Payments, Analytics, and Marketing.
- Strict compliance rules: Payments must be isolated from other apps, but Analytics and Marketing can share some data.
- Requirements:
- Central team must manage IP ranges, subnets, and firewall rules.
- Each app team wants its own project for billing and IAM separation.
- No direct internet access to databases; APIs must be reachable from private VMs.
Your task:
- Decide how many Shared VPC host projects you would use, and what they represent (for example: one for prod, one for nonprod; or one for Payments, one for others).
- Decide which projects would be service projects attached to which host.
- Sketch (mentally or on paper) which subnets you would create (e.g., `payments-web`, `payments-db`, `shared-analytics-web`, etc.).
- Identify at least two firewall rules you would need to:
- Allow user HTTPS traffic to public-facing web apps.
- Allow web-to-db traffic only on required ports.
- Decide where you would enable Private Google Access.
After you design it, compare to this reference approach:
- 1 Shared VPC host for Payments (prod/nonprod), 1 Shared VPC host for other apps.
- Payments, Analytics, and Marketing each as service projects to the appropriate host.
- Subnets split by tier (web/app/db) with strict firewall rules, PGA enabled on all private subnets.
Ask yourself: in an exam question, which details would you look for to justify this design?
Quiz 1: Shared VPC and Firewall Basics
Test your understanding of Shared VPC and firewall rule behavior.
You manage a Shared VPC. The security team wants to centrally control all firewall rules for every project using that network. What is the correct approach?
- Create firewall rules in each service project; they automatically apply to the Shared VPC subnets.
- Create all firewall rules in the host project; they apply to resources from attached service projects.
- Use VPC peering between the host and service projects so firewall rules can be synchronized.
- Move all resources from service projects into the host project so firewall rules can be applied centrally.
Show Answer
Answer: B) Create all firewall rules in the host project; they apply to resources from attached service projects.
In Shared VPC, the VPC network (and its firewall rules) live in the host project. Firewall rules are defined in the host project and apply to resources from attached service projects. Service projects do not define network-level firewall rules for the Shared VPC.
Quiz 2: Troubleshooting Connectivity
Apply what you know to a common troubleshooting scenario.
A VM without an external IP in a private subnet cannot reach Cloud Storage using `storage.googleapis.com`. There is a route to the internet via Cloud NAT, and firewall egress rules allow all traffic. What is the MOST likely missing configuration?
- A custom static route for `storage.googleapis.com` is missing.
- Private Google Access is not enabled on the subnet.
- A VPC peering connection to the Cloud Storage VPC is not configured.
- The VM needs a second network interface with an external IP.
Show Answer
Answer: B) Private Google Access is not enabled on the subnet.
For VMs without external IPs to reach Google APIs using only internal IPs, you must enable Private Google Access on the subnet. Cloud NAT can also be used, but the question emphasizes a private subnet and missing configuration, pointing to Private Google Access.
Key Term Review: Network Security and Shared VPC
Flip through these cards to reinforce core concepts before moving on.
- Shared VPC: host project
- The project that owns the VPC network(s), subnets, routes, and firewall rules and shares them with one or more service projects.
- Shared VPC: service project
- A project that attaches its resources (such as VM instances or GKE clusters) to subnets in a Shared VPC host project while keeping its own IAM and billing.
- Firewall rule priority
- An integer from 0 (highest) to 65535 (lowest). Rules are evaluated in order of increasing priority number; the first match wins.
- Implicit firewall behavior
- Firewall rules are stateful and there is an implicit deny-all rule at the end. If no rule matches, traffic is blocked.
- Private Google Access
- A subnet-level setting that lets VMs without external IP addresses reach Google APIs and services using their internal IPs.
- Private Service Connect (high level)
- A feature that creates private endpoints in your VPC so you can access Google APIs, Google-managed services, or third-party services without using public IPs.
- VPC peering
- A connection between two VPC networks that allows private IP communication while keeping each VPC’s routes and firewall rules separate. It is non-transitive.
- Per-environment isolation pattern
- Using separate VPCs (often in separate projects) for dev, test, and prod, optionally without peering, to strongly isolate environments.
- Least-privilege firewall design
- Creating narrowly scoped firewall rules that allow only required protocols, ports, and sources/destinations, often using tags or service accounts as targets.
- Role of the Associate Cloud Engineer in networking
- An Associate Cloud Engineer deploys and secures applications, services, and infrastructure, including configuring VPCs, firewall rules, and private access patterns to meet performance and security requirements.
Key Terms
- VPC
- A global, logically isolated virtual network in Google Cloud that contains regional subnets, routes, and firewall rules.
- Shared VPC
- A Google Cloud feature that lets you configure and centrally manage a VPC network in a host project and share its subnets with one or more service projects.
- Network tag
- A user-defined string applied to VM instances and used as a selector in firewall rules and some routing configurations.
- VPC peering
- A networking connection between two VPC networks that enables private IP communication while preserving each VPC’s separate routes and firewall rules; peering is non-transitive.
- Host project
- In a Shared VPC, the project that owns and shares the VPC network and its subnets with service projects.
- Firewall rule
- A stateful rule applied at the VPC level that allows or denies ingress or egress traffic to resources such as VM instances, based on priority, direction, targets, and protocol/port criteria.
- Egress traffic
- Network traffic leaving a VM or resource toward another destination.
- Ingress traffic
- Network traffic entering a VM or resource from another source.
- Service project
- In a Shared VPC, a project whose resources use subnets from a host project’s shared VPC network.
- Priority (firewall)
- A numeric value that determines the order in which firewall rules are evaluated; lower numbers are evaluated before higher numbers.
- Private Google Access
- A subnet-level configuration that allows VMs without external IP addresses to access Google APIs and services using only their internal IP addresses.
- Private Service Connect
- A Google Cloud networking feature that provides private endpoints in a consumer VPC to access Google APIs, Google-managed services, or third-party services without using public IPs.
- Perimeter / isolation pattern
- A network architecture approach that uses separate VPCs, Shared VPC, and/or VPC peering to control and limit which environments or projects can communicate.