Playbook

GKE workloads need to access GCP APIs without managing service account keys.

→Enable and configure Workload Identity on the GKE cluster. Map Kubernetes Service Accounts (KSA) to Google Service Accounts (GSA).

Why: Eliminates the risk of leaked service account keys by using short-lived, automatically-rotated credentials derived from KSA tokens.

Reference↗

Provide access to internal web apps from any network based on user identity and device posture, without a VPN.

→Use Identity-Aware Proxy (IAP) with Access Context Manager. Define access levels based on IP, device state (via Endpoint Verification), and user identity.

Why: Shifts access control from the network perimeter to individual users and devices, enforcing zero-trust principles.

Reference↗

A CI/CD pipeline (e.g., GitHub Actions, GitLab) needs to access GCP resources without long-lived credentials.

→Use Workload Identity Federation. Create a provider pool for the external IdP (e.g., GitHub OIDC) and configure attribute conditions to restrict access to specific repositories or branches.

Why: Keyless authentication for external workloads. The external system provides its own token, which is exchanged for a short-lived GCP token.

Enforce IAM security policies across the entire organization, such as preventing service account key creation or restricting IAM grants to specific domains.

→Use Organization Policy constraints like `iam.disableServiceAccountKeyCreation` and `iam.allowedPolicyMemberDomains`.

Why: Organization Policies are inherited and cannot be overridden by project owners, ensuring consistent security posture.

A user needs temporary, auditable, and approval-gated administrative access to a production environment for an incident.

→Use Privileged Access Manager (PAM) for just-in-time (JIT) access. The user requests a specific role for a limited time, which goes through an approval workflow.

Why: Eliminates standing privileges, a major security risk. Access is time-bound, justified, and fully audited.

Multiple teams share a GKE cluster. Each team must only manage resources within their own namespace.

→Grant IAM role `roles/container.clusterViewer` at the project level. Use Kubernetes RBAC `Role` and `RoleBinding` within each namespace to grant specific permissions (e.g., edit, view).

Why: Separates cluster-level authentication (IAM) from namespace-level authorization (Kubernetes RBAC), providing fine-grained, multi-tenant control.

APIs must be called using short-lived credentials instead of static keys.

→Use service account impersonation. Grant a principal the `roles/iam.serviceAccountTokenCreator` role on a target service account to generate short-lived OAuth 2.0 access tokens.

Why: Avoids distributing and managing long-lived keys. Tokens expire automatically (default 1 hour), reducing risk if compromised.

A contractor needs access to specific resources, but access must automatically expire after 30 days.

→Grant the necessary IAM role with a time-based IAM Condition, e.g., `request.time < timestamp("YYYY-MM-DDTHH:MM:SSZ")`.

Why: Automates access revocation, avoiding manual cleanup and ensuring access is not inadvertently prolonged.

Only allow container images that have been signed by the CI/CD pipeline to be deployed to production GKE clusters.

→Implement Binary Authorization. Create an attestation in the CI pipeline to sign images. Configure a Binary Authorization policy on the GKE cluster to require this attestation.

Why: Enforces a secure software supply chain by preventing unvetted or tampered images from running in production.

Reference↗

Grant permissions to resources based on their assigned tags, not individual resource names.

→Use IAM Conditions with resource tag expressions, like `resource.matchTag("123456789/env", "prod")`.

Why: Enables scalable, attribute-based access control (ABAC). Permissions are dynamic and apply automatically as resources are tagged.

Allow a service project to deploy VMs in a Shared VPC host project without granting network admin rights.

→In the host project, grant the service project's service account the `roles/compute.networkUser` role on the specific subnet(s) it needs to use.

Why: Follows least privilege. Service projects can use the network but cannot modify it (e.g., change firewall rules), which remains centrally managed.

A user with `storage.admin` cannot create a bucket. You need to identify the root cause.

→Check for an IAM Deny Policy at a higher level (folder, org) that denies the `storage.buckets.create` permission.

Why: IAM Deny policies always override any allow policies. This is a powerful tool for enforcing non-negotiable security boundaries.

Enable SSO for on-premises Active Directory users to access the Google Cloud console.

→Use Google Cloud Directory Sync (GCDS) to sync identities to Cloud Identity. Configure federation (SAML) between Cloud Identity and AD FS (or another IdP).

Why: Maintains AD as the source of truth for identities while providing a seamless, federated SSO experience for users.

Encrypt data in GCP, but the encryption keys must never leave the on-premises HSM.

→Use Cloud External Key Manager (EKM). This allows GCP services to use keys from an external key management system for CMEK operations.

Why: Provides maximum control and meets strict data sovereignty requirements by keeping key material outside of Google Cloud.

Reference↗

Automatically find and classify sensitive data (PII, PHI) across all Cloud Storage and BigQuery assets.

→Configure Cloud Data Loss Prevention (DLP) discovery scans. The results can automatically populate Data Catalog with tags.

Why: Provides an automated data inventory and classification, which is the foundation for data governance and protection policies.

An analytics team needs to query data containing PII, but should not see the raw sensitive values. Referential integrity must be maintained.

→Use a Cloud DLP de-identification template with deterministic encryption or cryptographic hashing.

Why: Transforms sensitive data into pseudonyms. Deterministic methods ensure the same input always produces the same output, allowing for joins and aggregations.

A compliance framework (e.g., for financial services) requires encryption keys to be protected by a FIPS 140-2 Level 3 certified HSM.

→Use Cloud KMS with a protection level of HSM. This creates keys within a managed Hardware Security Module.

Why: Meets high-level compliance requirements by using dedicated, certified hardware for key management without managing the physical HSMs.

Ensure new resources (e.g., GCS buckets, BigQuery datasets) are always encrypted with customer-managed keys (CMEK), not Google-managed keys.

→Apply the `constraints/gcp.restrictNonCmekServices` Organization Policy.

Why: Provides a preventative control that forces specified services to use CMEK, ensuring a consistent data protection posture.

Data must be stored in an immutable (WORM - Write-Once-Read-Many) state for a specific retention period for legal or compliance reasons.

→Configure a Cloud Storage bucket with a retention policy and enable Bucket Lock.

Why: Bucket Lock makes the retention policy irreversible, ensuring objects cannot be deleted or modified, even by administrators, until the retention period ends.

Application database credentials stored as secrets must be rotated automatically without causing application downtime.

→Use Secret Manager with automatic rotation configured. The rotation triggers a Cloud Function that updates the password in the database and creates a new secret version.

Why: Managed, automated rotation reduces the risk of credential compromise. Applications reference the `latest` version to seamlessly pick up the new secret.

A workload processes highly sensitive data, and the data must remain encrypted even while in memory (in-use).

→Use Confidential Computing by deploying the workload on Confidential VMs.

Why: Provides hardware-based memory encryption, protecting data from the hypervisor and other VMs. Use attestation to verify the integrity of the environment.

Restrict access to specific sensitive columns in a BigQuery table without creating separate views.

→Use BigQuery column-level security. Apply Data Catalog policy tags to sensitive columns and grant the "Fine-Grained Reader" role on those policy tags to authorized users/groups.

Why: Enforces fine-grained access directly on the table, which is more scalable and manageable than maintaining multiple authorized views.

Protect sensitive data in a GCS bucket even if IAM permissions are misconfigured and grant public access.

→Encrypt objects with a Customer-Managed Encryption Key (CMEK) and tightly control access to that key in Cloud KMS.

Why: Creates a two-key system. An attacker needs permissions for both the GCS object AND the KMS key to decrypt the data, providing defense-in-depth.

Prevent accidental or malicious immediate deletion of critical Cloud KMS keys.

→When creating the key, configure the `destroy_scheduled_duration` property to a value like 30 days.

Why: Enforces a waiting period before a key is permanently destroyed, providing a window to recover from accidental deletion.

A legal requirement to prove a file in Cloud Storage has not been altered since it was uploaded.

→Upon download, re-calculate the file's MD5 or CRC32C hash and compare it to the hash stored in the Cloud Storage object metadata.

Why: Provides cryptographic proof of object integrity. Cloud Storage automatically calculates and stores these hashes on upload.

Prevent data from being copied from a sensitive project to a public bucket, even by a user with `owner` role.

→Place the sensitive project within a VPC Service Controls perimeter. This restricts data movement to other projects outside the perimeter.

Why: VPC Service Controls act as a data-centric firewall that overrides IAM permissions for data egress, providing a powerful defense against exfiltration.

Reference↗

Protect a public-facing web application against volumetric DDoS attacks and common web exploits (e.g., SQLi, XSS).

→Place the application behind a Global External HTTP(S) Load Balancer and attach a Cloud Armor security policy with pre-configured WAF rules.

Why: The load balancer absorbs DDoS attacks at Google's edge. Cloud Armor provides a managed Web Application Firewall to block OWASP Top 10 threats.

A Dedicated Interconnect is used for on-prem to GCP connectivity, but traffic must be encrypted for compliance.

→Configure an HA VPN tunnel over the Cloud Interconnect VLAN attachments.

Why: Combines the high bandwidth and low latency of a dedicated connection with the IPsec encryption of a VPN.

On-premises systems need to call Google APIs (e.g., BigQuery, GCS) without traversing the public internet.

→Configure Private Google Access for on-premises hosts. Use Cloud Interconnect or VPN, and configure DNS to resolve `*.googleapis.com` to the restricted VIP range.

Why: Keeps traffic to Google services on Google's private network, enhancing security and potentially reducing egress costs.

Enforce mutual TLS (mTLS) for all service-to-service communication within a GKE cluster.

→Deploy Anthos Service Mesh (or Istio) and enable strict mTLS peer authentication for the relevant namespaces.

Why: Automatically encrypts and authenticates all traffic within the mesh, achieving a zero-trust network model without application code changes.

A consumer VPC needs to privately access a service (e.g., an internal API) running in a producer VPC without using peering or public IPs.

→The producer publishes the service using Private Service Connect. The consumer creates an endpoint in their VPC that privately routes to the service.

Why: Decouples network connectivity from service access. It is the modern, scalable way to provide private access to services across VPCs and organizations.

Deploy a GKE cluster where nodes have no public IPs and the control plane is not exposed to the internet.

→Create a Private GKE cluster. Enable Private Google Access on the subnet for node access to GCP APIs. Configure master authorized networks to restrict control plane access to specific IPs (e.g., corporate network).

Why: Significantly reduces the cluster's attack surface by removing public endpoints for both nodes and the control plane.

In a GKE cluster, pods for a `frontend` service should only be allowed to communicate with pods for a `backend` service, and nothing else.

→Create Kubernetes NetworkPolicy resources. Apply an ingress policy to the `backend` pods that allows traffic only from `frontend` pods, based on pod labels.

Why: Provides pod-level firewalling within the cluster, enabling a least-privilege network model for microservices.

VMs with no external IPs need to access the internet. All egress traffic must originate from a small set of predictable IP addresses for allowlisting by third parties.

→Configure Cloud NAT for the subnet containing the VMs.

Why: Provides managed network address translation for internet-bound traffic from private instances, with centralized logging and IP allocation.

Enforce a baseline firewall rule across the organization, such as denying all SSH from the internet, that cannot be overridden by project teams.

→Create a Hierarchical Firewall Policy at the organization or folder level with a deny rule for port 22 from `0.0.0.0/0` at a high priority.

Why: Hierarchical policies are evaluated before VPC-level rules, allowing central security teams to enforce non-negotiable network security guards.

Resolve internal hostnames within a VPC without leaking queries to public DNS servers.

→Configure a Cloud DNS private managed zone for your internal domains and associate it with your VPC.

Why: Provides authoritative DNS for internal resources within the VPC network, improving security and manageability.

When Security Command Center detects a threat (e.g., cryptomining), automatically isolate the affected VM.

→Configure SCC to publish findings to a Pub/Sub topic. Trigger a Cloud Function that receives the finding and modifies the VM's network tags to apply a pre-configured "quarantine" firewall rule.

Why: Enables near real-time, automated incident response, reducing the time an attacker has in the environment.

Collect audit logs from all projects in the organization and store them for 7 years in an immutable format for compliance.

→Create an organization-level log sink to a Cloud Storage bucket. Configure the destination bucket with a 7-year retention policy and Bucket Lock.

Why: An aggregated sink centralizes logs. Bucket Lock ensures the logs are tamper-proof and meet strict compliance retention requirements.

A VM is suspected to be compromised. It must be taken offline immediately, but evidence must be preserved for forensic analysis.

→Stop the VM instance (to halt activity) and immediately create a snapshot of its persistent disk. Then, isolate it with firewall rules.

Why: Stopping the instance contains the threat, while the snapshot creates a point-in-time copy of the disk for analysis without risk of evidence tampering.

Detect when a service account is being used from an unusual geographic location or is performing abnormal activities.

→Enable Security Command Center Premium tier, which includes Event Threat Detection. This service analyzes logs for anomalous behavior.

Why: Uses Google's threat intelligence and machine learning to detect threats that are difficult to find with rule-based alerts, such as compromised credentials.

A central security team needs to analyze and correlate security signals from GCP, AWS, and on-premises systems in a single platform.

→Ingest all relevant logs and telemetry into Chronicle Security Operations (SIEM).

Why: Chronicle is a cloud-native SIEM designed for petabyte-scale analysis, with built-in parsers and detection rules for multi-cloud and hybrid environments.

Detect when GCP resources managed by Terraform are modified manually via the console, creating configuration drift.

→Configure a Cloud Asset Inventory feed to send real-time asset change notifications to a Pub/Sub topic. A service can then compare these changes against the Terraform state.

Why: Provides real-time visibility into all resource changes, enabling automated detection of out-of-band modifications.

An organization has thousands of SCC findings and needs to focus on the ones that pose the most immediate risk to critical assets.

→Use Attack Path Simulation in SCC Premium. Define high-value assets and the simulation will identify and prioritize findings that form a direct path to those assets.

Why: Moves from vulnerability-based to risk-based prioritization. It highlights toxic combinations of findings that an attacker could exploit.

Detect malicious activity inside a running GKE container, such as an unexpected shell or a reverse shell connection.

→Enable Container Threat Detection in Security Command Center.

Why: Provides runtime visibility into container behavior, detecting threats that vulnerability scanning (which happens before runtime) cannot see.

A network forensics investigation requires capturing and analyzing the full packet content of traffic between two specific VMs.

→Configure Packet Mirroring to clone traffic from the source VMs and send it to a collector VM running inspection tools like Wireshark or Zeek.

Why: Provides full packet capture for deep analysis, unlike VPC Flow Logs which only contain metadata.

Prevent insecure Terraform configurations (e.g., public GCS buckets) from being deployed.

→Integrate a static analysis security testing (SAST) tool like `tfsec` or Checkov into the CI/CD pipeline. Fail the build if security violations are found.

Why: Implements "shift-left" security by catching misconfigurations before they are deployed, reducing the need for reactive remediation.

A company must ensure that for compliance reasons, certain data and processing can only occur in EU regions.

→Apply the `gcp.resourceLocations` Organization Policy constraint, allowing only specified EU regions.

Why: This is a technical, preventative control that enforces data residency at the resource creation level, which is required for regulations like GDPR.

A financial institution requires that Google support engineers must get explicit, time-bound approval before accessing their data for a support case.

→Enable Access Approval and configure approvers. All access requests from Google will generate a request that must be approved.

Why: Provides customer-gated control over Google administrative access, a key requirement for highly regulated industries.

An auditor needs to verify exactly what actions Google personnel took when they were granted access to your environment.

→Enable and review Access Transparency logs. These logs provide a near real-time feed of actions taken by Google staff.

Why: Provides an immutable audit trail of Google administrator actions, giving visibility and supporting compliance requirements.

Continuously monitor the GCP environment for configurations that violate a specific compliance standard, like PCI DSS or HIPAA.

→Use Security Health Analytics in Security Command Center, with the relevant compliance standard enabled in the dashboard.

Why: Automates compliance checks against industry benchmarks, providing continuous visibility and generating findings for any detected misconfigurations.

An auditor requests Google's SOC 2 Type II report and PCI DSS Attestation of Compliance.

→Use the Compliance Reports Manager in the Google Cloud console to access and download audit reports and certifications.

Why: Provides a self-service portal for customers to obtain necessary compliance documentation to support their own audit processes.

A US government agency needs to deploy a workload that meets FedRAMP High compliance requirements.

→Deploy the application within an Assured Workloads environment configured for the FedRAMP High compliance regime.

Why: Assured Workloads automatically applies the necessary controls and guardrails (e.g., data location, personnel access restrictions) to help meet specific compliance standards.