Networking
Index ▾
- 01. Concepts
- 02. Architecture
- 03. State & Storage
- 04. Tools
- 05. BigQuery
- 06. Cloud Storage
- 07. Compute & Containers
- 08. Cloud Run
- 09. Pub/Sub
- 10. Databases
- 11. Observability
- 12. Access & Billing
- 13. Secret Manager
- 14. Networking
- 15. Scheduling & Tasks
- 16. Build & Artifacts
- 17. Guardrails
- 18. Setup
- 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.