As more organizations accelerate their digital transformation, cloud-native architectures and containerized workloads have become the foundation for innovation and scalability. Yet, with this evolution comes a shifting security landscape—one that is more dynamic, distributed, and complex than ever before. Protecting these modern environments demands not just traditional safeguards, but an adaptive, layered security strategy capable of keeping pace with rapid change.
Fortinet brings a robust portfolio of security solutions tailored for these challenges, empowering teams with deep visibility, granular control, and unified protection from code to cloud. In this article, we’ll explore essential pillars and proven best practices for Google Kubernetes Engine (GKE), including the use of private clusters to limit exposure, Workload Identity to securely map Kubernetes workloads to Google Cloud IAM, Binary Authorization to ensure only trusted container images are deployed, and Shielded GKE Nodes to strengthen node-level integrity. You’ll also discover how FortiCNAPP safeguards Kubernetes workloads, how FortiGate enhances visibility into outbound traffic patterns, and how the FortiWeb Ingress Controller defends external-facing services against evolving threats.
Whether your goal is to harden workloads, optimize performance, or boost resilience, this guide will show how combining best practices with Fortinet’s integrated platform can help you confidently secure your cloud-native applications in today’s fast-moving threat landscape.
GKE Benchmark Best Practices
Google Kubernetes Engine (GKE) delivers a fully managed Kubernetes service, but securing it effectively requires following proven best practices. Applying industry benchmarks such as the CIS Kubernetes Benchmark and Google Cloud’s GKE hardening guidelines helps ensure that your clusters are secure, reliable, and cost-efficient. When using FortiCNAPP for Kubernetes Security Posture Management (KSPM), it’s important to understand how its capabilities support compliance enforcement and strengthen the overall security posture of your GKE environment.
Key Considerations:
Private Clusters
- Configure your clusters and node pools without exposing public endpoints, significantly reducing the attack surface. This ensures that both the control plane and the nodes remain inaccessible from outside the internal network. In need of public services, detailed architecture will be presented for the Ingress traffic.
Workload Identity
- Use dedicated identities for each workload instead of the default Compute Engine service account. Workload Identity Federation securely authenticates with Google Cloud APIs while avoiding the exposure of sensitive metadata.
Binary Authorization
- Enforce deployment policies that ensure only container images signed by trusted sources can be deployed. This strengthens your software supply chain by allowing you to define and enforce strict security rules.
Shielded GKE Nodes
- Protect the integrity of your nodes through cryptographic identity and verification, preventing node impersonation even if bootstrap credentials are compromised.
GKE Networking Best Practices for Visibility and Control
Networking is a critical component of GKE security. The choice of networking mode directly impacts how traffic is routed, inspected, and controlled—especially when integrating with Fortinet solutions like FortiGate and FortiWeb.
Networking Recommendations:
- Use VPC-native (alias IPs) networking when you need full pod IP visibility for traffic inspection and policy enforcement with FortiGate.
- Avoid routes-based networking for security-sensitive workloads, as it limits pod-level visibility and flexibility in policy enforcement.
- For large-scale clusters with constrained IP space, carefully plan secondary IP ranges to avoid conflicts and ensure scalability.
- Design your VPC and subnet CIDR allocations to accommodate future growth and avoid IP exhaustion.
- Apply custom routes and VPC firewall rules to direct egress traffic through FortiGate for inspection, logging, and threat prevention.
- Use FortiWeb for ingress protection and FortiCNAPP for runtime visibility, compliance enforcement, and policy management.
- Restrict pod access to the GCP Instance Metadata Server by enabling Workload Identity or using firewall rules to block access to 169.254.169.254, preventing unauthorized retrieval of sensitive metadata and service account tokens.
Code & Container Scanning: Understanding Vulnerabilities
In today's fast-paced development environments, containerized applications are becoming the norm. However, with this shift comes the critical need for robust security measures. Code and container scanning are essential practices to identify and mitigate vulnerabilities within containerized applications. These scans help detect issues in the base images, application code, and dependencies, ensuring that potential security weaknesses are addressed before deployment.
Key Considerations:
- Minimize unnecessary content in container images.
- Configure container images to run as unprivileged users.
- Reference container images by sha256 digests or validate the image's digital signature at deploy time via admission control.
- Regularly scan container images during creation and deployment, and patch known vulnerable software.
- (Optional for GKE) Leverage Google Cloud Artifact Registry vulnerability scanning to automate detection of known vulnerabilities in container images stored within GCP.
FortiCNAPP for Kubernetes Admission Control
FortiCNAPP integrates seamlessly with Kubernetes Admission Controllers to enhance security during the deployment process. By using the ValidatingAdmissionWebhook, FortiCNAPP scans container images for vulnerabilities before they are deployed, ensuring that only secure images are admitted into the production environment. This proactive approach helps prevent the introduction of vulnerabilities and maintains the integrity of your GKE clusters.
Key Considerations:
- Enable an appropriate selection of admission controllers.
- Enforce a pod security policy using Pod Security Admission or a webhook admission controller.
- Securely configure the admission chain plugins and webhooks.
See Integrate with Kubernetes Admission Controller
FortiCNAPP Pod Visibility
Visibility into Kubernetes pods is crucial for maintaining security and operational efficiency. FortiCNAPP offers both sidecar and agent options to monitor pod activity. These agents provide detailed insights into processes, network connections, and other critical metrics within the pods. By leveraging these visibility options, organizations can detect and respond to threats in real time, ensuring the security of their containerized applications running on GKE.
Key Considerations:
- Apply appropriate Pod Security Standards policy for all namespaces and enforce it.
- Set memory limits for workloads with a limit equal to or less than the request.
- Enable Seccomp with appropriate syscalls profile for programs on supported nodes.
- Enable AppArmor or SELinux with appropriate profiles for programs on supported nodes.
Architecture Overview
The proposed architecture is a secure and scalable Google Cloud deployment model designed for containerized workloads running on Google Kubernetes Engine (GKE). It incorporates both a Web Application Firewall (WAF) for secure ingress—implemented with FortiWeb—and a Next-Generation Firewall (NGFW) for secured and inspected egress traffic—implemented with FortiGate. This setup follows Zero Trust principles while enabling centralized security enforcement, comprehensive observability, and high availability across the GKE environment.
There is a special project assigned to the security hub with trusted/internal VPC and an untrusted/external VPC. There is a project for the GKE cluster, and there are several options for the interconnection with the security hub, peering is one of them.
Ingress Traffic Protection with FortiWeb
Securing incoming traffic is critical to protecting Kubernetes workloads in Google Kubernetes Engine (GKE) from external threats. FortiWeb enhances ingress security by providing advanced capabilities such as a Web Application Firewall (WAF), SSL/TLS termination, and intelligent load balancing. These features work together to block malicious requests, minimize the risk of data exposure, and ensure that only trusted traffic reaches your applications.
Although FortiWeb can operate as a Kubernetes Ingress Controller, its primary strength lies in augmenting the security posture of publicly accessible services, regardless of the ingress solution deployed in your GKE environment.
Key Considerations:
- Use WAF policies tailored to your application stack to detect and block common web exploits (e.g., SQL injection, XSS).
- Terminate SSL/TLS at the edge to offload encryption overhead and securely inspect traffic.
- Apply geo-blocking and IP reputation filtering to reduce exposure to known malicious sources.
- Enable bot mitigation and DDoS protection to defend against automated and volumetric attacks.
- Log and monitor ingress traffic patterns to detect anomalies and respond to threats in real time.
- Integrate with Kubernetes-native resources (e.g., ConfigMaps, Secrets) for dynamic and secure configuration management.
- Ensure high availability and failover for ingress traffic to maintain service continuity.
Egress Traffic Visibility with FortiGate
Monitoring egress traffic in Google Kubernetes Engine (GKE) is crucial for detecting and preventing data exfiltration, command-and-control communications, and other malicious outbound activity. FortiGate provides deep visibility and control over egress flows, ensuring that all outbound connections from workloads are inspected, logged, and filtered in alignment with Zero Trust and compliance requirements.
How FortiGate Enables Egress Control in GKE
FortiGate integrates with the Google Cloud SDN Connector to dynamically discover Kubernetes resources such as pods, services, and namespaces in GKE. This integration allows FortiGate to:
- Automatically populate dynamic address groups based on Kubernetes metadata (e.g., k8s_namespace, k8s_podname, k8s_label).
- Apply adaptive firewall policies that adjust in real time as workloads scale or change.
- Enforce egress control by blocking unauthorized outbound traffic, including attempts to reach sensitive endpoints like the Kubernetes API server, kubelet, and Google Cloud metadata service.
Key Considerations:
- Ensure that the CNI plugin supports Kubernetes NetworkPolicies.
- Apply ingress and egress NetworkPolicies to all workloads in the cluster.
- Implement a default deny network policy in each namespace to block all traffic unless explicitly allowed.
- Ensure that the Kubernetes API, kubelet API, and etcd are not exposed publicly.
- Filter access from workloads to the Google Cloud metadata API.
- Restrict usage of LoadBalancer and ExternalIPs to prevent unintended exposure.
In this design, all outbound traffic from GKE workloads is routed through FortiGate, where NAT and inspection are performed before reaching the internet or external services. This ensures comprehensive logging, policy enforcement, and threat detection on every egress flow.
Conclusion
Securing workloads in Google Kubernetes Engine (GKE) requires a holistic, layered security strategy that combines network segmentation, workload isolation, and continuous monitoring. Fortinet’s solutions — including FortiCNAPP, FortiGate, and FortiWeb — provide deep visibility, adaptive policy enforcement, and advanced threat protection across the entire Kubernetes lifecycle.
By applying the best practices described in this guide and integrating Fortinet’s security capabilities with GKE and Google Cloud services, organizations can reduce their attack surface, strengthen compliance alignment, and ensure high availability for critical applications. This approach positions teams to operate securely and efficiently in modern, cloud-native environments.
Connect with our Cloud Consulting Services team for expert guidance on advanced configurations and production deployments:
Email: consulting@fortinet.com
Learn more: Cloud Security Consulting Services
