Google Cloud Platform Security Best Practices | Hacker News Reader

Google Cloud Platform Security Best Practices

assured.se

184 pointsJoachimS15 comments

Some of Google's own guidance on the topic:

https://cloud.google.com/blog/products/identity-security/don...

I'm working on a low-bandwidth cloud development environment for remote work using Terraform, and I currently have a bastion box, no incoming firewall rules for the non-bastion hosts, but they do have public IPs. I'm guessing this is the ideal use case for Cloud NAT?

I'm a beginner so I don't want to make any elementary security mistakes.

In the setup tasks - I need to create an osLogin permission, which means my service account for terraform needs elevated permissions, is there a better way of managing this? Could I perhaps configure that account with `gcloud` and then do the rest with terraform? Is that more secure?

Additionally, I want to pull code from github to non-bastion instances. Is there a good way to get a ssh key onto each box, securely and automatically, to allow github access? Consider that I might want to spin up a new disk and instance for dev at any time.

Identity aware proxy supports SSH tunneling which means you don't need to manage a bastion.

https://cloud.google.com/iap/docs/using-tcp-forwarding#tunne...

For connecting VMs without public IPs to the outside world, Cloud NAT is the easiest answer. You could set one up yourself if you were so inclined (e.g. some forwarding rules and iptables rules on the bastion).

For ssh key distribution, there's a few options. You can store the key in Secret Manager and run your GCE VMs as a service account that has access to the key, then fetch it when pulling.

https://cloud.google.com/secret-manager/docs/

Something like:

$ ssh-add <(gcloud beta secrets versions access latest --secret=github-ssh-key)

On startup. I haven't actually tried out secret manager yet.

If you have too much time on your hands, you could rig something up with GCE vTPMs as well :)

https://cloud.google.com/blog/products/gcp/virtual-trusted-p...

SSH with IAP over TCP is dope, so is IAP in general for hiding internal websites and tools. There is still some edge case you may want a bastion (e.g. access a private GKE master). For most use cases, you are right, IAP TCP replaces the need for a bastion host. Actually, in this case, their proxy is the bastion host, but hey!

As fart as managing SSH keys, I would say: don't do it. Use OS Login instead. For cases, like automation, create a service account and use it with OS Login. It gives you a centralized way to manage SSH access (and revoke access) and sudo privileges.

https://cloud.google.com/compute/docs/oslogin/

I'm currently using osLogin, but wondering if there's a good way to connect to private github repos from each VM. I think ssh keys are the answer for that, but I have no idea! Thanks to both of you for the info - I'll read up on all this stuff!!!

Thank you for your advice! I'll likely end up using some of these - although I think vTPM is a little beyond me!

If they have public IPs, cloud NAT won’t apply to them. CloudNAT only NATs VMs that do NOT have public IPs.

As a sibling has said, use IAP ssh tunneling instead of bastions. With cloudNAT enabled you can pull code from any public repo, including GitHub.

For edge traffic, use any of the gcp provided LBs... there are a bunch of them and they’re all very good. If you’re on GKE I would highly recommend datawires’ ambassador edge proxy: easy to setup and configure, and envoy is a modern, fast and reliable LB.

Maybe I'm missing something but if your boxes have public IPs and no firewall rules, why do you need a bastion? What's stopping any random person from connecting?

As I understand it - incoming connections on all ports are blocked?

ed: Sorry, I see. No firewall rules means by default that outgoing connections are allowed, but no incoming ones.

Reply on news.ycombinator.com