If you’re going to protect yourself from getting hacked, it helps to understand how you get hacked in the first place. Here are 3 attack vectors for your GCP account, and some best practices to lock them down. Note: Cloud security is a shared responsibility model between Google and you as a customer
Obviously, if you share your credentials publicly, 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.
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).
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.
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 GCP access keys you’ve stored in the GCP 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.
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.
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 GCP 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.
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.
You’ve undoubtedly heard this 1000 times as well. Don’t grant your IAM Roles more permissions than they absolutely need for the software running on the instance.