Securing Private Nomad Clusters with Google Cloud IAP
This episode demonstrates how to expose a private Nomad cluster's administrative UI securely using Google Cloud's Identity-Aware Proxy (IAP). The presenters walk through configuring a global load balancer that sits in front of a managed instance group running three Nomad servers in a private VPC. Because the cluster is completely isolated with no inbound traffic allowed, the load balancer provides the necessary ingress point while IAP adds an authentication layer that forces users to authenticate with authorized Google accounts before accessing the admin interface. This architecture ensures that sensitive administrative interfaces remain protected while still being accessible to authorized personnel.
Infrastructure as Code Implementation with Terraform
The implementation uses Terraform to provision multiple interconnected Google Cloud resources including a static IP address, backend service targeting the managed instance group, URL map for traffic routing, HTTPS proxy, forwarding rules, and managed SSL certificates. The presenters demonstrate live coding practices including proper resource dependencies, health check configuration, and DNS setup using the domain nomad-on-google.cloud. A key limitation surfaces during implementation: OAuth 2.0 client credentials for IAP must be created manually through the Google Cloud Console rather than via Terraform, as the API only supports internal organization clients programmatically. The session includes troubleshooting IAM role bindings, showing how the iap.httpsResourceAccessor role must be granted to users before they can successfully authenticate through IAP.
Production Readiness Roadmap and Next Steps
While the episode successfully establishes secure access to the Nomad UI, the presenters emphasize this is foundational work toward a production-ready cluster. Future episodes will cover deploying actual workloads, setting up public-facing load balancers for application traffic, implementing storage interfaces, configuring Docker bridge networking, service discovery with Traefik for internal routing, and autoscaling based on resource allocations rather than just CPU usage. The working cluster now displays three healthy servers with proper leader election and three client nodes, all visible through the authenticated web interface, providing a solid platform for the advanced topics ahead.
