GCP Networking Overview

Networking in the GCP Campus Cloud is centrally managed. You cannot create VPC networks yourself — a deny policy blocks VPC creation for all users. Only the Cloud Team’s automation account can provision network resources.

Your project is automatically attached to the campus Shared VPC at provisioning, giving you outbound internet access via Cloud NAT immediately. For anything beyond that, open a ServiceNow ticket.

Current State

Capability Available?
User-created VPCs No — blocked by policy
Shared VPC attachment Yes — your project is attached to the campus Shared VPC automatically at provisioning
Internet egress via Cloud NAT Yes — provided via the Shared VPC; no ticket required
VPC peering Not available (contact Cloud Team if needed)
Campus connectivity (VPN/Interconnect) Not available — no direct path to the UCSB campus network exists at this time

Org Policy Networking Constraints

The following constraints are enforced across all projects:

  • No VPC creation — users cannot create VPC networks; only the Cloud Team’s automation can provision them.
  • Custom-mode VPCs only — auto-mode VPCs (which create subnets in every region) are blocked by a custom constraint.
  • No external IP addresses on VMs — VMs may not have public IPs. Outbound internet access is provided via Cloud NAT.
  • Allowed regions: us-central1 (Iowa) and us-west1 (Oregon) only.
  • VPC flow logs required — subnets without flow logs cannot be created.

Requesting Network Resources

Your project is automatically attached to the campus Shared VPC at provisioning and receives outbound internet access via Cloud NAT — no ticket is needed for basic connectivity.

For anything beyond standard outbound access (additional subnets, VPC peering, firewall rule changes), open a ServiceNow ticket (Cloud Services) with:

  • Your GCP project ID
  • What you need and why
  • The region (us-central1 or us-west1)
  • Any specific CIDR or peering requirements

Adding Team Members to the Shared VPC

Your project and its default service accounts can use the campus Shared VPC right away — no request needed. The project owner is also granted access at provisioning.

Other team members and additional service accounts do not have Shared VPC access by default. Because subnet access is controlled in the host project — not your project — you cannot grant it yourself, even as the project owner.

To request access for additional users or service accounts, open a ServiceNow ticket and include:

  • Your GCP project ID
  • The Google identity (email address) of each person or service account that needs access

Accessing Private VMs Without a Public IP

Since VMs cannot have external IPs, use Identity-Aware Proxy (IAP) for SSH and RDP access. IAP tunnels traffic securely without requiring a VPN or public IP.

See Google’s official guide: Using IAP for TCP forwarding

Network Tags for IAP Access

Your VM must have the correct network tag for IAP to reach it. Without these tags, no inbound traffic is allowed — not from the internet, not from IAP.

Network Tag What It Enables
allow-iap-ssh SSH access (port 22) via IAP
allow-iap-rdp RDP access (port 3389) via IAP
allow-win-activation Windows license activation (KMS egress)

How to add a network tag:

  • Console: Go to your VM instance → Edit → scroll to Networking → enter the tag name in the Network tags field → Save.
  • gcloud: gcloud compute instances create my-vm --tags=allow-iap-ssh (or add to an existing VM with gcloud compute instances add-tags).
  • Terraform: Add tags = ["allow-iap-ssh"] to your google_compute_instance resource.

SSH Access

  • Console SSH button: Open the VM in the Cloud Console and click SSH. This uses IAP automatically — no local software needed.
  • gcloud: gcloud compute ssh VM_NAME --tunnel-through-iap

RDP Access

  • IAP Desktop (recommended): Download IAP Desktop — a free Windows app that handles IAP tunneling and RDP in a single window. No gcloud installation required.
  • gcloud tunnel: gcloud compute start-iap-tunnel VM_NAME 3389 --local-host-port=localhost:3389, then connect your RDP client to localhost:3389.

Required IAM Roles

To connect via IAP, users need:

  • roles/iap.tunnelResourceAccessor — permission to create IAP tunnels
  • roles/compute.osLogin (or roles/compute.osAdminLogin) — OS Login access to the VM

OS Login

OS Login is enforced by org policy across all GCP Campus Cloud projects. This means SSH access uses your Google identity — there are no project-wide SSH keys to manage, share, or rotate.

What this means for you:

  • Console SSH just works. Click the SSH button in the Cloud Console; it handles OS Login automatically.
  • gcloud SSH just works. gcloud compute ssh uses your Google identity by default.
  • You cannot disable OS Login in project metadata. The org policy overrides any project-level setting.
  • Traditional SSH keys (project metadata or instance metadata) are ignored when OS Login is enforced.

If your project has a specific need to disable OS Login (e.g. a Marketplace image that is incompatible), open a ServiceNow ticket and the Cloud Team will evaluate an exception.

Public-Facing Services

Serverless services like Cloud Run, Cloud Functions, and API Gateway can serve public internet traffic by default — no org policy exception is needed.

For VM-based workloads that need a public-facing endpoint (e.g., a web application behind a load balancer), open a ServiceNow ticket. The Cloud Team will provision an external Application Load Balancer with Cloud Armor (Google’s WAF and DDoS protection) on your behalf. You cannot create external load balancers yourself — they are blocked by org policy.

Services That Work Without a VPC

Many GCP services do not require a VPC at all:

  • Cloud Storage
  • BigQuery
  • Pub/Sub
  • Cloud Functions
  • Cloud Run
  • Vertex AI

If your workload uses only managed services, you may not need to request network provisioning.