Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Google Cloud Platform Security Best Practices (assured.se)
184 points by JoachimS on Dec 19, 2019 | hide | past | favorite | 15 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!


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.


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.


[flagged]


I find it funny when people complain about Google monoculture in browsers and search engines, but also complain about GCP not being the biggest player.


What? How are those things even remotely the same?

Monoculture in browsers and search engines means they can exploit their dominant monopoly position to be abusive to the community.

GCP not being the biggest means there's not enough momentum to satiate googles avarice, which leads to ambivalence towards customers who have critical infrastructure on their systems.


[flagged]


Google documents didn't show that a day or two ago. A third-party article quoting only unnamed sources made claims about Google's thinking early last year before several executive hiring and other actions which show some real serious effort towads GCP's success, and which claims Google has officially said were "not accurate".

I wish Google were making a clearer public push to make their actual plans widely known, but they've long been bad at PR, so I don't read anything into it either way.

(Disclaimer: I used to work for Google, including the GCP team, but I haven't done so since early 2015 and do not have firsthand authoritative knowledge on the accuracy of the allegations from the article - I don't need insider knowledge to know that the public record is currently ambiguous. I'm certainly not speaking for Google here.)


You’re getting downvoted because it’s a lazy, value-free trolling post with no supporting information or analysis. For example, you could explain why you think a strategic paid service contracted to large organizations is likely to have the same lifespan as a free consumer service without a good revenue model.


In addition to your reasons, I also downvoted the comment because it is completely irrelevant; whether or not GCP might someday be shut down has nothing at all to do with security best practices on the platform.

If you wanted to discuss GCP's likelihood of sticking around, this top story from earlier this week would have been an appropriate place: https://news.ycombinator.com/item?id=21815260


> "Reports of these conversations from 2018 are simply not accurate," the spokesperson said in a statement

https://www.crn.com/news/cloud/google-reportedly-set-ambitio...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: