3 ms·

Likely security in layers. Why expose your control plane to attacks directly from the internet if you don't have to? Cuts down login attempts noise in logs sinc

Likely security in layers. Why expose your control plane to attacks directly from the internet if you don't have to? Cuts down login attempts noise in logs since anything would have to be coming from the VPC. Other than initial setup of a bastion -- that's the tradeoff -- sounds like less to worry about for a small shop or a startup. Same for Cloud SQL or any other managed service.

Ironlink 4y ago
I wish they would reuse the pattern of Cloud SQL where you can get temporary access without manually handling the Authorized Networks setting. The Cloud SQL API lets you exchange your API access token for a short lived TLS client certificate. This is done client side by things like cloudsql-proxy[1] and the cloud-sql-jdbc-socket-factory java library[2]. This way, I can access my Cloud SQL instance from my IDE, even though my list of authorized networks is empty. I feel like the gke-gcloud-auth-plugin cloud do something very similar. [1]: https://github.com/GoogleCloudPlatform/cloudsql-proxy https://github.com/GoogleCloudPlatform/cloudsql-proxy [2]: https://github.com/GoogleCloudPlatform/cloud-sql-jdbc-socket-factory https://github.com/GoogleCloudPlatform/cloud-sql-jdbc-socket...
solatic 4y ago
But setting up a bastion has its own issues. Now I need to monitor and patch it regularly, which with a 100% Kubernetes shop means I need a completely separate setup for it. How do I protect my bastion against DDoS? 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.
- no_circuit 4y ago
  You probably already have CI/CD so a scheduled action on something like running Terraform would notice that your VM OS image version just got updated and automatically replace your bastion. That image seems to update every few days. You don't lose any data since persistent disk(s) are attached. I'd be surprised if anyone with automation still manually logs into machines to run apt-get update and upgrade -- cloud-init and/or crontab should do that for you. 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.

Ironlink 4y ago

I wish they would reuse the pattern of Cloud SQL where you can get temporary access without manually handling the Authorized Networks setting. The Cloud SQL API lets you exchange your API access token for a short lived TLS client certificate. This is done client side by things like cloudsql-proxy[1] and the cloud-sql-jdbc-socket-factory java library[2]. This way, I can access my Cloud SQL instance from my IDE, even though my list of authorized networks is empty. I feel like the gke-gcloud-auth-plugin cloud do something very similar. [1]: https://github.com/GoogleCloudPlatform/cloudsql-proxy https://github.com/GoogleCloudPlatform/cloudsql-proxy [2]: https://github.com/GoogleCloudPlatform/cloud-sql-jdbc-socket-factory https://github.com/GoogleCloudPlatform/cloud-sql-jdbc-socket...

solatic 4y ago

But setting up a bastion has its own issues. Now I need to monitor and patch it regularly, which with a 100% Kubernetes shop means I need a completely separate setup for it. How do I protect my bastion against DDoS? 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.

no_circuit 4y ago
You probably already have CI/CD so a scheduled action on something like running Terraform would notice that your VM OS image version just got updated and automatically replace your bastion. That image seems to update every few days. You don't lose any data since persistent disk(s) are attached. I'd be surprised if anyone with automation still manually logs into machines to run apt-get update and upgrade -- cloud-init and/or crontab should do that for you. 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.