GCP security cheatsheet


IAM (Identity and Access Management) - a service that lets you specify who gets to do what on which resources.

Identity - an entity that represents a person or a service account that perform actions on GCP.

  • Google account - a person’s account with a gmail or G-Suite address.
  • Service account - an application account.
  • Cloud Identity - if a person doesn’t have a Google account then we can create a substitute for them - a Cloud Identity.

Groups - collections of Identities. Create a Group with a set of permissions, assign a bunch of Identities to it and voila - all these Identities now have the Group’s permissions.

Principal - an Identity or a Group

Resource - a GCP project, a VM, a Cloud Storage bucket, a Pub/Sub topic - anything that we can create on GCP.

Permission - a grant assigned to a Role to perform certain actions. Permissions cannot be assigned directly to Identities or Groups.

Role - a set of permissions. Can be assigned to an Identity or a Group.

  • Predefined Roles - created and managed by GCP. Cannot be altered or deleted. E.g.: roles/bigquery.admin
  • Primitive Roles - 3 legacy roles that grant excessive permissions: Viewer (read access to all resources), Editor (read/write access to all resources), Owner (full access to all resources including IAM and Billing)
  • Custom Roles - user defined roles, duh...

Scopes - a legacy method of limiting permission for VMs.

Default service accounts - 2 service accounts created automatically on GCP with the Primitive Editor Role. That’s a legacy practice, delete them and use custom Service Accounts with Custom Roles assigned.

Policies - bindings between Principals and Roles.

We can use Conditions to define under what circumstances a Role is being available for a Principal. Condition types: Schedule, Expiration date, Resource Type, Resource Tag, Resource Service, Resource Name.

Security Design Principles

Separation of Duties (SoD) - limit the responsibilities of a single individual in order to prevent the person from successfully acting alone in a way detrimental to the organization.

Least Privilege - grant only the minimal permissions needed to perform the duties.

Defense in Depth - use more than one security control, because any security control might be compromised

Relevant regulations

HIPAA (Health Insurance Portability and Accountability Act) - a US federal law that protects individuals’ health information. Pay attention to the Privacy Rule and Security Rule. The Privacy Rule limits what data can be shared by legal entities who have access to the protected information. It also grants patients the rights to review information in their records. The Security Rule sets technical standards for protecting the data. Read more.

HITECH (Health Information Technology for Economic and Clinical Health) - sets the rules for transmission of the protected data.

GDPR (General Data Protection Regulation) - a EU law that sets rules for individuals’ privacy protection and specify security practices required for any organizations holding private information of EU citizens.

SOX (Sarbanes-Oxley Act) - a US federal law that prevents public companies from tampering with financial data. Sets data retention periods, requires annual audits and certain key management techniques.

COPPA (Children’s Online Privacy Protection Act) - a US federal law that regulates collection and processing children's private information.

Best practices checklist

Do not use Primitive Roles. Google recommends using Predefined Roles as much as possible. Use Custom Roles when Predefined Roles are not fine-granted enough.
Treat each Resource as a separate trust boundary. E.g. if multiple VMs require different permissions, then create separate Service Accounts with least Permissions in each case.
Remember that Policies are inheritable.
The IAM Admin Role gives access to modifying
Rotate Service Accounts’ keys by creating a new key, replacing the old one in the application that needs it and then disabling the old key.
Do not use Service Accounts keys when possible. Use alternative Service Account authentication methods.
Use Cloud Audit Logs to audit changes to IAM and other critical services.
Grant Roles to Groups instead of individual Identities when possible.
Default Firewall rules are too permissive. Use custom firewall rules. For public services consider limiting IP ranges by country [relevant discussion]
Don't use automatic role grants for default service accounts [link].

Data encryption at-rest

Data is encrypted at-rest by default with a Data Encryption Key (DEK). The DEK is encrypted with a Key Encryption Key (KEK). DEKs are kept near the data that they encrypt. KEKs are stored in a centralized key management service. Google rotates KEKs.

Encryption happens at multiple levels:

  • Platform level. AES256 and AES128 encryption.
  • Infrastructure level. Data grouped into chunks and each chunk encrypted using AES256.
  • Hardware level. Storage devices apply AES256 or AES128 encryption.

Data encryption in-transit

Data that doesn’t leave boundaries of Google network is authenticated but may not be encrypted. Data outside the physical boundaries of the Google network is encrypted

Service Accounts

Disable automatic role grants for default Service Accounts because by default they are granted the Primitive Editor role which gives read/write access to almost all GCP resources.

Avoid creating Service Account keys.

Treat Service Accounts as Resources associated with specific VMs (for instance), not Identities, associated with specific people.

Do not share Service Accounts between different services.

Name Service Accounts after the Resources they are associated with, because Cloud Audit logs include the names of the Service Account that performed the audited action, but not the name of the Resource that used this Service Account.

Recommended naming convention:

  • vm- for service accounts attached to VMs
  • wi- - for Workload Identity
  • wif- - workload identity federation
  • onprem- - on-premises applications

Do not embed sensitive information in the account name or description.

Disable Service Accounts before deleting them.

Never delete default Service Accounts. Never generate keys for them.

Avoid using access scopes. It’s a legacy feature.

Use Credential Access Boundaries when giving short-lived access to third-party applications.

Don't let users create or upload Service Account keys.

The following Permissions enable users to impersonate Service Accounts:

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.getOpenIdToken
  • iam.serviceAccounts.actAs
  • iam.serviceAccounts.implicitDelegation
  • iam.serviceAccountKeys.create
  • iam.serviceAccountKeys.get
  • deploymentmanager.deployments.create
  • cloudbuild.builds.create

The following Roles enable users to impersonate Service Accounts:

  • Owner (roles/owner)
  • Editor (roles/editor)
  • Service Account User (roles/iam.serviceAccountUser)
  • Service Account Token Creator (roles/iam.serviceAccountTokenCreator)
  • Service Account Key Admin (roles/iam.serviceAccountKeyAdmin)
  • Service Account Admin (roles/iam.serviceAccountAdmin)
  • Workload Identity User (roles/iam.workloadIdentityUser)
  • Deployment Manager Editor (roles/deploymentmanager.editor)
  • Cloud Build Editor (roles/cloudbuild.builds.editor)

Limit shell access to VMs that have a privileged service account attached.

To be continued...