I feel like the gke-gcloud-auth-plugin cloud do something very similar.
[1]: https://github.com/GoogleCloudPlatform/cloudsql-proxy
[2]: https://github.com/GoogleCloudPlatform/cloud-sql-jdbc-socket...
Managed VPN services have their own costs and worries. Don't want to accidentally pay for tunneled Netflix or YouTube? More configuration and maintenance.
What kind of attacks from the Internet need to be worried about here? Basically just zero-days? But that's true for any bastion or VPN as well, and again, Google is managing the control plane so they're empowered to roll out the patch faster than a small customer could.
If there aren't any DNS entries pointing to my bastion host(s), then I'd find it unlikely that a DDoS would ever specifically be directed to them. Pretty easy to recreate them in another region, and/or put them behind something like Cloudflare.
References: [1] https://cloud.google.com/kubernetes-engine/docs/best-practic...
What's the point of requiring the control plane to be locked down to authorized networks (IP address ranges)? Isn't Google responsible for DDoS protection, enforcing authentication controls (i.e. logging in with a Google account in the right Google group), patching the control plane ASAP for any security vulnerabilities?
If you have a VPN, if you have heavy-duty network monitoring on your VPN endpoint, sure, limit it to the VPN. For the rest of us? Is every startup running GKE without heavy-duty VPN / network monitoring fundamentally insecure? That doesn't sound right to me. Security is supposed to be a spectrum, and it seems like black-and-white automated config checkers like these are more likely to provoke arguments internally ("but the tool said it's bad!!") than to help reach a nuanced understanding of why tradeoffs are made. No?