Skip to content
Community previewValidate controls against current Google documentation.Report a gap

Google Kubernetes Engine (GKE) Security

Google Kubernetes Engine (GKE) is Google Cloud’s managed Kubernetes service that provides a secure, scalable platform for containerized applications. This section covers security best practices, compliance requirements, and implementation guidance for GKE environments.

  • Shielded GKE Nodes: Secure boot, virtual trusted platform module (vTPM), and integrity monitoring
  • Private Clusters: Nodes without public IP addresses, accessible only via private Google Cloud networks
  • Authorized Networks: IP allowlisting for API server access
  • Workload Identity: Secure pod-to-GCP service authentication
  • Network Policies: Kubernetes-native traffic control between pods
  • Service Mesh: Istio/Anthos Service Mesh for advanced traffic management
  • Private Service Connect: Private connectivity to Google APIs
  • Binary Authorization: Deploy-time security controls for container images
  • FIPS 140-2 Compliance: Validated cryptographic modules for data protection
  • FedRAMP Authorization: High-impact level compliance for government workloads
  • PCI DSS: Payment card industry compliance capabilities
  • HIPAA: Healthcare data protection compliance
Guide What it covers Status
FIPS 140-2 Compliance FIPS-compliant storage options and cryptographic validation in GKE Available
Cluster Hardening CIS-aligned GKE cluster configuration Planned
Workload Identity Pod-to-Google Cloud authentication without service account keys Planned
Network Policies Zero Trust networking with Kubernetes network policy Planned
Terminal window
# Check if Shielded GKE nodes are enabled
gcloud container clusters describe CLUSTER_NAME \
--zone=ZONE \
--format="value(shieldedNodes.enabled)"
# List authorized networks
gcloud container clusters describe CLUSTER_NAME \
--zone=ZONE \
--format="table(masterAuthorizedNetworksConfig.cidrBlocks[].cidrBlock)"
# Check if private cluster is enabled
gcloud container clusters describe CLUSTER_NAME \
--zone=ZONE \
--format="value(privateClusterConfig.enablePrivateNodes)"
Terminal window
# Check if Workload Identity is enabled
gcloud container clusters describe CLUSTER_NAME \
--zone=ZONE \
--format="value(workloadIdentityConfig.workloadPool)"
# List service accounts with Workload Identity bindings
gcloud iam service-accounts list --filter="displayName:gke-"
Terminal window
# Export current Binary Authorization policy
gcloud container binauthz policy export
# List attestors
gcloud container binauthz attestors list
Terminal window
# Create node pool with FIPS-compliant boot disk
gcloud container node-pools create fips-pool \
--cluster=CLUSTER_NAME \
--zone=ZONE \
--image-type=COS_CONTAINERD \
--enable-gvnic \
--metadata=google-compute-enable-fips=TRUE
# Example: Deny all ingress traffic by default
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
# Example: Enforce restricted security policy
apiVersion: v1
kind: Namespace
metadata:
name: secure-namespace
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
Compliance Framework GKE Support Key Requirements
FIPS 140-2 ✅ Supported Use validated crypto modules, FIPS-mode nodes
FedRAMP High ✅ Supported Use compliant regions, enable audit logging
PCI DSS ✅ Supported Network segmentation, encryption, access controls
HIPAA ✅ Supported Encryption at rest/transit, audit logs, BAAs
SOC 2 ✅ Supported Security controls, monitoring, incident response
  1. Use Autopilot Mode when possible for Google-managed security hardening
  2. Enable Shielded GKE Nodes for enhanced node security
  3. Implement Workload Identity instead of service account keys
  4. Use Binary Authorization to ensure only verified images are deployed
  5. Enable audit logging and ship logs to Cloud Logging
  6. Regularly update clusters and nodes to latest versions
  7. Implement network policies for pod-to-pod traffic control
  8. Use private clusters to reduce attack surface

Page provenance

Community-maintained guidance. Use the edit link below to propose a sourced correction.

Contributors

Was this page useful?

Help us prioritize the next improvement.