.jpg)
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 to improve your project’s security. If you’re not able or don’t want to make every change, it’s still beneficial to implement a subset of them. They individually improve security. Read further and get to know more about necessary IAM security. Also, don’t miss the rest of this series:
Article III.: How to Make Your Google Cloud Platform Project More Secure: Built-In GCE Security
Article IV.: How to Make Your Google Cloud Platform Project More Secure: GCE Network Security
Article V.: How to Make Your Google Cloud Platform project more secure: GCE OS Security
Multi-factor Authentication is a method where in addition to using one piece of information to authenticate a user (e.g. a password), at least one additional source of proof is needed to ensure the right person is accessing a system.
On Google Cloud Platform, users authenticate themselves using Google Accounts. These are 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 Google Accounts having access to your project to have MFA enabled. But if you only grant access to users from your Google Suite Domain, then the Administrator can set up MFA on it so that it forces everyone to use it. What if you need to give access to people without accounts in your Google Suite Domain? 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.
The password policy settings are technically not inside the Google Cloud Platform. They are 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, 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.
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, don’t grant your database administrators performing only Google Cloud SQL administration tasks a Project Editor role. Give them a Cloud SQL Admin role instead.
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. If the instance is running Linux, 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, consult the documentation for details.
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, a faulty script creating resources in a recursive manner will 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.
You can change the quotas on the Quotas page, but it requires the serviceusage.quotas.update permission. This permission 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, the spending can only increase up to the quota limits.
There is another type of account on Google Cloud Platform besides the user accounts: Service Accounts.
Service accounts are meant for programmatic use cases. You can’t use them to access the Google Cloud Console as 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. This way, 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. You can achieve this by creating a new key for the service account. Then, you have to overwrite the current key with the new one everywhere it was saved. Lastly, you need to delete the old key associated with the service account. This way, the attacker will only have a limited time window to use the key. Even if an application where the key was stored is compromised without your knowledge.
You can find some additional information on the Google Cloud Platform documentation about IAM security on this page.
If your organization is a big enterprise, you should check out the security guidelines written especially for bigger customers here.
