This is the second in a series of posts about Google Cloud Platform security. The first post deals with security in general and security design of the Google Cloud Platform.
This post contains practical, actionable settings you can modify in the IAM which will greatly improve the security of your project. If you’re not able to or don’t want to make every change, then it’s still beneficial to implement a subset of them, because each one individually improves your security.
Enforce Multi-factor Authentication (MFA)
Multi-factor Authentication is a method where not only is one piece of information used to authenticate a user (e.g. a password), but there’s also at least one additional source of proof needed to establish that the right person is accessing a system.
On Google Cloud Platform, users authenticate themselves using Google Accounts. These can be individual email addresses registered as a Google Account or (more commonly) accounts of a Google Suite Domain. On the Google Cloud Platform side, you cannot enforce that the Google Accounts that have access to your project must have MFA enabled. But if you only grant access to users from your Google Suite Domain, then the Google Suite Domain Administrator can set up MFA on the Google Suite Domain in a way that forces everyone to use it. If you need to give access to people without accounts in your Google Suite Domain, then you can create accounts for them in your Google Suite Domain for the sole purpose of accessing your project. This way you can enforce settings on their accounts.
If you combine both these rules, then you can be certain that every user who has access to the Google Cloud Platform project needs to validate themselves using MFA. This makes it much harder to compromise your project, even if the password for an email address leaks from another source.
Here you can find the information about how to enforce MFA (for Google Suite Domains, MFA uses 2 factors) authentication for Google Suite Domains: https://support.google.com/a/answer/2548882
Set-up password policy for users
The password policy settings are technically not inside the Google Cloud Platform but at the discretion of the Google Suite Domain Administrator. If you only allow users from your domain and the domain is set up with the right password policy, then these two things combined will result in the password policy being enforced on all of your GCP users.
Here you can find more information about how to set up password requirements for your Google Suite Domain: https://support.google.com/a/answer/139399?hl=en
Give the necessary but the least possible privileges
It is good practice in general to only give the minimum necessary privileges to all of your users. If all of the previously discussed account protection methods fail, your attackers will still have fewer services to break into or steal information from.
The actual implementation of this principle will vary based on your usage patterns. For example, if your database administrators only need to do Google Cloud SQL administration tasks, don’t give them a Project Editor role; give them a Cloud SQL Admin role instead.
Double check the Google Compute Engine related roles
Most of the roles in IAM are easy to understand. They even have descriptions to help decide which one you want to use for a specific scenario. There are some notable exceptions though, where it is quite hard to decide which role is enough for a specific operation. For example, Google Compute Engine (GCE) related roles are a bit convoluted, especially since new rules have been introduced which are in the beta stage now.
The most important thing to note is that a lot of GCE-related roles grant you SSH access to the instances themselves. And, if the instance is running Linux, then GCE creates the account in a way that allows you to sudo to become root. If you don’t want this “side effect” when you assign GCE-related roles, then you should consult the documentation for details: https://cloud.google.com/compute/docs/access/
Set up Quotas
Default quotas are set for every newly created project on Google Cloud Platform. This is a last-resort security control to avoid unexpected runaway spending. For example, if you have a faulty script creating resources in a recursive manner, it’ll only be able to create them up to the quota limits. It can also protect against a compromised account creating a lot of new resources for the attacker’s purposes.
The quotas can be changed on the Quotas page, but it requires the serviceusage.quotas.update permission, which is only included in the following predefined roles: Owner, Editor, and Quota Administrator. So, if a compromised account or faulty script does not have this permission, then the spending can only increase up to the quota limits.
Check and rotate Service Account keys
There is another type of account on Google Cloud Platform besides the user accounts: Service Accounts.
Service accounts are meant for programmatic use cases. They cannot be used to access the Google Cloud Console because they are only valid for Google Cloud API access. The most frequent use case is to run applications or instances inheriting the rights of a specific service account, so they can access other cloud services without extra authentication. You can read in detail about how to use service accounts in combination with GCE in the third post of the series.
Service accounts use keys for authentication. One service account can have multiple keys associated with it. It is a good practice to regularly rotate the keys of the service account. This can be achieved by creating a new key for the service account, then overwriting the current key with the new one everywhere it was saved, and then deleting the old key associated with the service account. This way, even if an application where the key was stored is compromised without your knowledge, the attacker will only have a limited time window to use the key.
Further reading about IAM security
You can find some additional information on the Google Cloud Platform documentation about IAM security on this page: https://cloud.google.com/iam/docs/using-iam-securely
If your organization is a big enterprise, you should check out the security guidelines written especially for bigger customers here: https://cloud.google.com/docs/enterprise/best-practices-for-enterprise-organizations
