Ferris Hall
ferrishall.dev

ferrishall.dev

Google Cloud 101.1

Google Cloud 101.1

Ferris Hall's photo
Ferris Hall
·Nov 11, 2022·

3 min read

Subscribe to my newsletter and never miss my upcoming articles

So recently this week I have been getting back to basics in Google Cloud, various mentoring and preparation for delivering training classes on getting started with Google Cloud infrastructure.

So it got me thinking, I should probably put some best practice tips on here. I'm not going to be writing about what a VM is and what the cloud is, I'm assuming most reading this have been there already.

So this is more of a "I've spun up a VM using default config, now what?" next step post. Well, this is where I'll add some pointers.

IAM and least privilege

image.png

So I'll start with Compute Engine, that's pretty much where everyone starts?! You may have noticed that when you create a Compute Instance, it'll come configured as a default to use the project's default Compute Engine service account, easy right?! Well yes but not overly best practice or secure.

Take a look at the IAM page and you'll notice that the default Compute Engine service account comes locked and loaded with the "Editor" role, again great what's the problem?! I can use that to do what I need and no more config is needed, awesome! Well, that is the problem!

The editor role is way too overpowered and broad for a VM that might just need access to a Cloud Storage bucket or maybe Cloud SQL.

To get into the habit of best practice we should be using IAM securely and only giving Google Cloud Identities like users and service accounts IAM roles to access services or do the jobs they need to, nothing more.

That way if our Compute Engine VM or the service account attached to it were to become comprised or mistakes during deployment happens, the blast radius is smaller and no unnecessary access can be leveraged.

Our Compute Engine VM, depending on what it is being used for, say for this example a web server. We would create a dedicated service account that has the IAM role roles/storage.objectAdmin this then allows the Compute Engine VM the permission to create, update, delete etc objects within Google Cloud Storage buckets.

Great! This ensures that the VM has no unnecessary IAM roles to do anything or have access to anything that we don't intend for it to do.

The practice of least privilege should be used for all IAM roles for identities and service accounts when creating Google Cloud resources, there's more info on this on the IAM Google doc which explains it nicely.

VPC Network

image.png

While we're at it with our Compute Engine VM, when you first spin one up you probably attached it to a network, right? the default VPC?

That's fine but we can level this up a bit by getting rid of the default VPC network and creating a custom VPC network with subnets in the region we're working in.

This controls what our subnet IP ranges are and what region we have our subnets created in. We can also get more control over the firewall rules and not have the default firewall rules available to use.

We really don't want to have firewalls that we don't intend on using and we don't want a "default-allow-ssh" firewall rule to all instances in our VPC that is available to 0.0.0.0.

Again, this all points to best practices and ensuring security by design, having those security considerations in mind when creating resources in Google Cloud.

I didn't include any step-by-step instructions on how to do these steps, it's too late in the evening, but it's always worth taking a look the next time you're in a Google Cloud project (just don't test in production!)

Please feel free to reach out if you have any thoughts or feedback, I'm always happy to get constructive feedback and to keep learning!

 
Share this