
Google Cloud Platform Security Best Practices - JoachimS
https://www.assured.se/2019/12/19/gcp-security/
======
9nGQluzmnq3M
Some of Google's own guidance on the topic:

[https://cloud.google.com/blog/products/identity-
security/don...](https://cloud.google.com/blog/products/identity-
security/dont-get-pwned-practicing-the-principle-of-least-privilege)

------
tomlockwood
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.

~~~
dward
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...](https://cloud.google.com/iap/docs/using-tcp-
forwarding#tunneling_with_ssh)

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/](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...](https://cloud.google.com/blog/products/gcp/virtual-trusted-
platform-module-for-shielded-vms-security-in-plaintext)

~~~
jmarcher
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/](https://cloud.google.com/compute/docs/oslogin/)

~~~
tomlockwood
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!!!

