GCP Security Best Practices: Google Cloud Configuration Guide for 2026

Google Cloud IAM has three tiers of roles: basic roles (Owner, Editor, Viewer), predefined roles (service-specific roles like roles/storage.objectAdmin or roles/bigquery.dataViewer), and custom roles. Basic roles grant extremely broad permissions: the Editor role grants create, update, and delete permissions on most resources across the project, and the Owner role additionally grants IAM policy management. Assigning Owner or Editor to service accounts or even human users on production projects is a high-severity misconfiguration that gives any compromised identity broad blast radius across the project.

The correct approach is to use predefined roles scoped to the specific resource a principal needs to access. A Cloud Run service that needs to read from a specific Cloud Storage bucket should be granted roles/storage.objectViewer on that specific bucket, not on the project. A data pipeline that writes to BigQuery should be granted roles/bigquery.dataEditor on the specific dataset, not the Editor role on the project. IAM Recommender analyzes actual API usage over a rolling 90-day window and generates recommendations to replace overly permissive role bindings with minimum-permission alternatives. Running IAM Recommender across all projects in an organization regularly is one of the highest-return IAM hygiene activities available.

For human access, use groups in Google Workspace or Cloud Identity rather than individual user IAM bindings. Group-based access management scales better, simplifies access reviews, and ensures that role assignments are automatically revoked when a user leaves the organization and is removed from the group. Audit IAM bindings at the organization, folder, and project level on a quarterly cadence using the Cloud Asset Inventory API, looking for allAuthenticatedUsers and allUsers bindings (which grant access to any Google account or any internet user respectively), primitive role assignments on production projects, and service accounts granted high-privilege roles on the organization or folder level.

Service account hygiene requires specific attention because service accounts authenticate both as identities (they can be impersonated by humans) and as resources (they can be granted roles like any other principal). The two most common high-risk patterns are service accounts with downloaded JSON key files and service accounts granted the Service Account Token Creator or Service Account Admin role, which allows creating tokens for any other service account. The target state is zero downloaded key files for service accounts used in GCP-native workloads (replaced by Workload Identity for GKE and Compute Engine default service accounts for VM-based workloads) and zero downloaded key files for external workloads (replaced by Workload Identity Federation).

GCP VPC firewall rules control traffic at the network level and are applied to VM instances based on network tags or service account membership rather than subnet boundaries (unlike AWS security groups, which are applied to network interfaces, or Azure NSGs, which are applied to subnets or NICs). GCP VPC networks do not have a default deny-all rule for ingress; instead, they have implied deny-all ingress and allow-all egress rules at the lowest priority. The default network created automatically in new projects includes permissive allow rules for common ports (SSH, RDP, ICMP) that should be removed in production environments.

Hierarchical firewall policies, configured at the organization or folder level, allow network security teams to define baseline rules that apply across all VPCs in scope and cannot be overridden by project-level firewall rules at lower priority. This is the GCP equivalent of Azure Policy for network controls: a security team can define organization-level rules that deny all inbound management port traffic from the internet and allow specific egress patterns, then project teams operate within that baseline. Project-level firewall rules can add more permissive rules within the allowed space defined by hierarchical policies.

Private Google Access enables VM instances without external IP addresses to reach Google APIs and services (Cloud Storage, BigQuery, Pub/Sub, etc.) using internal IP addresses rather than routing through the internet. For the majority of Compute Engine workloads, assigning external IP addresses is unnecessary and creates attack surface. Use Private Google Access in combination with no external IP assignment as the default for all VMs, reserving external IPs only for resources that explicitly require direct internet connectivity. For GKE nodes, configure private cluster mode to eliminate external IP addresses from both nodes and the control plane.

VPC Service Controls are the strongest available preventive control for data exfiltration from GCP managed services. By creating a service perimeter around projects containing sensitive data, you prevent calls to in-scope APIs (like Cloud Storage or BigQuery) from succeeding if they originate from outside the perimeter, even with valid credentials. This prevents an attacker with stolen credentials from accessing BigQuery data from an external location or copying Cloud Storage data to a different project. Implementing VPC Service Controls in dry-run mode first is critical: the initial scan will surface legitimate cross-perimeter flows (CI/CD pipelines, data sharing with partner organizations, BigQuery data transfers) that require explicit ingress and egress rules before enforcement mode is activated.

Google Cloud encrypts all data at rest by default using AES-256 with Google-managed encryption keys. Customer-managed encryption keys (CMEK) via Cloud Key Management Service (Cloud KMS) replace Google-managed keys with keys that you control in your GCP project or in an external key manager. CMEK provides two primary security benefits: you can revoke a key to prevent decryption of associated data even by Google infrastructure, and you have an audit log of every key operation including wrapping and unwrapping operations used during encryption and decryption of data. CMEK is supported for Cloud Storage, BigQuery, Compute Engine persistent disks, Cloud SQL, GKE Secrets, Pub/Sub, and Cloud Spanner, among other services. The key rotation policy should be set to 90 days or less for keys protecting regulated data.

Secret Manager is the correct storage location for application secrets, database credentials, API keys, and certificates in GCP environments. It provides versioning (allowing zero-downtime secret rotation by creating a new version before deprecating the previous), IAM-controlled access with per-secret binding granularity, audit logging of all secret access operations, and optional automatic replication across regions. Storing secrets in environment variables, hardcoded in application code, or in Cloud Storage buckets in plaintext are all patterns that Secret Manager replaces. Applications running on GCP services should access secrets at startup via the Secret Manager API using the service account's Managed Identity (for Compute Engine and Cloud Run) or Workload Identity (for GKE pods), never storing the secret value beyond the running process memory.

Cloud Data Loss Prevention (Cloud DLP) API provides discovery and inspection capabilities for identifying sensitive data in Cloud Storage buckets, BigQuery tables, and Datastore instances. Organizations handling PII, payment card data, or health information should run periodic Cloud DLP inspection jobs across their data stores to identify data that has migrated to locations outside of expected security controls. Cloud DLP also provides de-identification transformations (tokenization, masking, pseudonymization) that can be applied to sensitive fields before data is made available to lower-privilege users or analytics pipelines. The Cloud DLP findings can be exported to Security Command Center, creating a unified view of data risk alongside infrastructure misconfigurations and threat detections.

Preventing public GCS bucket exposure requires both preventive and detective controls. The storage.publicAccessPrevention Organization Policy constraint is the most reliable preventive control, blocking public access configuration at the org or folder level regardless of individual bucket settings. For buckets that legitimately need to serve public content (static websites, public software distribution), the explicit exception to this policy should be documented and reviewed periodically. Security Command Center Standard automatically surfaces public buckets as findings, providing detective coverage for environments where the preventive org policy cannot be applied.

Security Command Center provides the unified security monitoring foundation for GCP environments. At the organization level, SCC aggregates findings from Security Health Analytics (misconfiguration detection), Event Threat Detection (real-time threat detection using Google's threat intelligence applied to Cloud Audit Logs), Container Threat Detection (eBPF-based runtime threat detection for GKE pods), VM Threat Detection (memory-based malware detection for Compute Engine instances), and Web Security Scanner (automated vulnerability scanning for HTTP-accessible applications). SCC Premium is licensed per asset, making cost predictable and proportional to environment size.

Cloud Audit Logs generate three log types that together provide comprehensive visibility into GCP resource activity. Admin Activity logs capture API calls that create, modify, or delete resources (including IAM policy changes) and are always enabled and cannot be disabled. Data Access logs capture API calls that read resource configurations or user-provided data; these are disabled by default and must be explicitly enabled for each service, with particular priority on BigQuery, Cloud Storage, Cloud SQL, Cloud KMS, and Secret Manager for environments handling sensitive data. System Event logs capture GCP infrastructure activity and are always enabled. Retaining these logs for at least one year (90 days in hot storage plus archive) is required by many compliance frameworks and allows investigation of incidents discovered weeks or months after they occurred.

Exporting logs to BigQuery for long-term retention and analysis is the standard pattern for organizations building security analytics capabilities on GCP. Log sinks can be configured at the organization level to export all audit logs from all projects to a centralized BigQuery dataset in a dedicated logging project, providing a single query surface for cross-project investigation. Google Chronicle (now part of Google Security Operations) ingests these logs and applies Google-scale threat intelligence and detection rules built by Google's Mandiant team, providing SIEM and SOAR capabilities purpose-built for cloud environments. Pub/Sub can serve as an intermediate export target when logs need to be consumed by external SIEMs or SOAR platforms in real time.

Log-based alerts configured in Cloud Monitoring allow teams to trigger notifications from specific log entries without waiting for a scheduled SIEM rule evaluation cycle. High-value alert configurations include alerts on IAM policy changes at the organization or project level (using the protoPayload.methodName of SetIamPolicy), changes to Organization Policy constraints, creation or deletion of VPC firewall rules, disabling of audit logging, and creation of service account keys. These alerts serve as a fast-path notification channel for the highest-severity administrative actions while longer-correlation SIEM rules process the full log stream.

The Organization Policy Service provides over 200 built-in constraints that enforce preventive security controls across all projects in a GCP organization. Unlike IAM policies which control who can take actions, Organization Policies control what actions can be taken by anyone, including project owners. High-priority constraints to enable at the organization level include compute.restrictCloudArmor (require Cloud Armor for external HTTP services), compute.requireOsLogin (require OS Login for SSH to Compute Engine instances, eliminating project-wide SSH keys), iam.disableServiceAccountKeyCreation (prevent creation of service account JSON keys organization-wide), storage.publicAccessPrevention (prevent public access to Cloud Storage buckets), compute.vmExternalIpAccess (restrict external IP assignment to specific VM instances or prevent it entirely), and sql.restrictPublicIp (prevent Cloud SQL instances from being assigned public IP addresses).

The GCP resource hierarchy (Organization, Folder, Project) is the primary mechanism for policy inheritance and blast radius containment. A well-designed hierarchy separates production, non-production, and shared infrastructure workloads into separate folders, applies environment-appropriate policy constraints at the folder level, and uses project-level isolation to limit the impact of any single compromised service account or misconfiguration. Production projects should have stricter Organization Policy constraints (deny service account key creation, deny public GCS buckets, deny public SQL IPs) while development folders may relax some constraints to preserve developer productivity.

Assured Workloads is Google's managed compliance solution for regulated industries, providing certified control packages for FedRAMP Moderate, FedRAMP High, HIPAA, PCI DSS, ITAR, and IL4 workloads. Assured Workloads configures a set of Organization Policy constraints, data residency requirements, and access control configurations appropriate for the selected compliance regime, and monitors the environment for control drift. For organizations with formal compliance certification requirements in these frameworks, Assured Workloads reduces the configuration burden of implementing the required controls while providing continuous compliance monitoring.

Security Health Analytics findings in Security Command Center are mapped to compliance framework controls for CIS Google Cloud Foundations Benchmark, PCI DSS, NIST 800-53, and ISO 27001, providing a continuous gap assessment against each framework. The compliance posture view in SCC Premium shows the percentage of controls met, controls with active findings, and controls with no findings, allowing compliance teams to track remediation progress over time and export evidence for audit purposes.

Google Kubernetes Engine (GKE) clusters require deliberate hardening because the defaults prioritize ease of deployment over security. The most impactful cluster-level security configurations are enabling private cluster mode (which removes external IP addresses from nodes and routes API server access through a private endpoint), enabling Workload Identity (which replaces node-level service account tokens with per-pod short-lived credential tokens mapped to specific GCP service accounts), enabling the GKE network policy provider (Calico or Dataplane V2) to enforce NetworkPolicy resources for pod-to-pod traffic control, and disabling the legacy metadata server endpoint to prevent pods from querying node metadata for service account tokens.

Binary Authorization is a GCP deploy-time security control that enforces a policy requiring all container images deployed to GKE to have attestations from approved signers before deployment is permitted. In practice, this means that a CI/CD pipeline vulnerability scanner must sign the image after passing a vulnerability scan, and the Binary Authorization policy on the cluster will reject any image without that signature. This prevents unvetted or tampered container images from being deployed to production even if an attacker gains write access to the container registry or the deployment pipeline. Binary Authorization policies can be set to dry-run mode for initial deployment to identify images that lack required attestations before enforcement begins.

Artifact Registry (replacing the older Container Registry) provides vulnerability scanning of stored container images through integration with Container Analysis. Vulnerability findings are categorized by severity and CVE identifier, and can be used as inputs to Binary Authorization attestation policy: images with Critical or High severity unfixed vulnerabilities fail the attestation step in CI/CD. Node auto-upgrade should be configured on all GKE node pools to apply Google-released node OS images automatically on a weekly schedule, ensuring that kernel patches and OS-level security fixes are applied without requiring manual operator action. This is particularly important for GKE Standard mode clusters where node management is not handled automatically by Google.

Pod Security Admission (the successor to Pod Security Policy, which was removed in Kubernetes 1.25) enforces security standards at the namespace level using three built-in profiles: Privileged (unrestricted), Baseline (prevents most known privilege escalation paths), and Restricted (strongly hardened, requires pods to run as non-root with read-only root filesystems). Production namespaces should be configured with the Baseline or Restricted profile enforced, with exceptions documented and approved for workloads with legitimate needs for elevated permissions. Defender for Containers (available through Google's partnership with Microsoft or through native GKE security features) provides runtime threat detection at the pod level using eBPF sensors.

Cloud Build is the native CI/CD service for GCP and runs on a dedicated service account that should be provisioned with minimum required permissions. By default, Cloud Build uses a service account with Editor role on the project, which is excessively permissive: a compromised build pipeline or malicious dependency can modify IAM policies, access secrets, or exfiltrate data. Replace the default Cloud Build service account with a custom service account granted only the specific permissions the build pipeline requires: typically roles/artifactregistry.writer for pushing images, roles/run.developer for deploying Cloud Run services, and specific resource-level permissions for any GCP resources the pipeline needs to configure.

Cloud Build steps that include container image builds should integrate with Artifact Registry vulnerability scanning and Binary Authorization attestation signing as part of the build pipeline. A security gate step that queries the Container Analysis API for the scanned image's vulnerability findings and fails the build if Critical or High unfixed vulnerabilities are present ensures that only scanned, compliant images advance to deployment. Combining this with Binary Authorization enforcement on the target GKE cluster creates a two-point enforcement: the pipeline will not produce a signed attestation for a vulnerable image, and the cluster will not deploy an image without a valid signed attestation.

Infrastructure as code scanning should be integrated into pull request workflows for all Terraform, Pulumi, or Google Cloud Deployment Manager configurations targeting GCP resources. tfsec and Checkov both include GCP-specific check libraries that identify misconfigurations including storage buckets without uniform bucket-level access, GKE clusters without private nodes, Cloud SQL instances without SSL required, and IAM bindings using basic roles. The Security Command Center API can be queried programmatically to check the security posture of existing infrastructure and surface findings as part of deployment pipeline quality gates.

Web Security Scanner, part of SCC Premium, provides automated OWASP-category vulnerability scanning for applications deployed on App Engine, Cloud Run, or accessible via GKE Ingress. It identifies common web vulnerabilities including XSS, mixed content, outdated JavaScript libraries, and insecure authentication configurations without requiring code access. Running Web Security Scanner scans on a weekly schedule against staging and production endpoints provides continuous detection of web-tier vulnerabilities that would otherwise require manual penetration testing to surface. Findings from Web Security Scanner appear in the Security Command Center findings interface alongside infrastructure misconfigurations, providing a unified security posture view from code through to running applications.