0% 0% 0% 0%

Networking

Index
  1. 01. Concepts
  2. 02. Architecture
  3. 03. State & Storage
  4. 04. Tools
  5. 05. BigQuery
  6. 06. Cloud Storage
  7. 07. Compute & Containers
  8. 08. Cloud Run
  9. 09. Pub/Sub
  10. 10. Databases
  11. 11. Observability
  12. 12. Access & Billing
  13. 13. Secret Manager
  14. 14. Networking
  15. 15. Scheduling & Tasks
  16. 16. Build & Artifacts
  17. 17. Guardrails
  18. 18. Setup
  19. 19. Deploy to Cloud Run

Networking

Answer “what’s on the network, and what can reach it?” from Slack — across VPC networks, firewall rules, and Cloud DNS. Every tool here is read-only: networking changes are high-blast-radius (a bad firewall or DNS edit can black-hole a service or a whole domain), so they belong behind dedicated, resource-level guardrails rather than a generic approval button.

VPC & firewalls

  • list_vpc_networks(project_id) — the VPC networks in a project, each flagged auto or custom subnet mode with its subnet count.
  • list_firewall_rules(project_id) — every firewall rule with its direction (ingress/egress), whether it allows or denies, and whether it’s disabled. The fast way to spot an overly-open rule from a thread.

Cloud DNS

  • list_dns_zones(project_id) — the managed zones in a project, each with its DNS name.
  • list_dns_records(zone, project_id) — the record sets in a zone (name, type, TTL, and values), so you can confirm what a domain resolves to without leaving Slack.

Why no writes here

Reads run under your own Google identity, so you only ever see what your IAM already permits. Firewall and DNS writes are deliberately absent — the same stance as the missing Cloud SQL and billing writes: too much blast radius for a single Approve/Deny. See Guardrails.

Next: Scheduling & Tasks.