If you’re going to protect your google cloud platform account from getting hacked, it helps to understand how you get hacked in the first place. Here are 3 attack vectors for your google cloud platform account, and some best practices to lock them down. Note: Cloud security is a shared responsibility model between Google and you as a customer

#1: Leaked GCP Credentials

Obviously, if you share your credentials publicly Handling Compromised Google Cloud Credentials, bad people can do bad things with them. And you wouldn’t do that, right? But mistakes happen, more often than you might think. This particular attack vector most commonly arises from access keys getting committed to public source code repositories. Typically, the committer thought the repository was private and the google cloud platform account hacked as its compromised.


Don’t Store Secrets In Source Control

Never check access keys, passwords, or other secrets into source control. It doesn’t matter if the repo is private. Manage them in a secret store that can be accessed at runtime (sometimes at deploy time).

Don’t Store Secrets At All

All of the GCP compute services allow you to specify an IAM Role for their compute instances (GCE(Google Compute Engine), GKE(Google Kubernetes Engine), GAE(Google App Engine),Cloud Functions and Cloud Run) to run as. When you use IAM Roles, the access keys are automatically provided to the process you don’t have to handle them at all.

#2:  Compromised Laptop (Or Desktop/workstation)

When bad people steal access to your computer, they have access to do all kinds of things. At the very least, they can easily discover any google cloud platform account access keys you’ve stored in the google cloud platform credentials file. They may also be able to log key presses, including the password you enter into the GCP console. You don’t want that as this would result in your google cloud platform account hacked.


MFA(Multi-Factor Authentication)

You’ve heard it 1000 times before, but you should be using multi-factor authentication when accessing your production GCP account. This is commonly used to control access to the GCP console, but you should also use it at the command line, and for any programmatic access that originates from your machine.

#3: Compromised Compute Instance

As mentioned above, compute instances (GCE(Google Compute Engine), GKE(Google Kubernetes Engine), GAE(Google App Engine),Cloud Functions and Cloud Run) in GCP can optionally run as an IAM Role, which implicitly grants the software on those instances the ability to access other resources in your google cloud platform account.  The scope of access depends on the policies applied to the IAM Role.

If an attacker compromises your compute instance. They can get these keys. And if the associated IAM Role is granted permission to do nefarious things, the attacker can do those nefarious things. That’s not a good thing.


Apply Your Security Patches!

Whether it’s a script, a docker container or a full operating system running on a GCE instance, you need to make sure you’re up to date on your security patches. Not staying current on fixes to well-publicized security vulnerabilities is just asking for trouble.

Least Privilege For Your IAM Roles

You’ve undoubtedly heard this 1000 times as well. Don’t grant your IAM Roles IAM Roles more permissions than they absolutely need for the software running on the instance.