Understand network security in GKE

This document explains core GKE network security concepts, such as the principle of least privilege, and helps you choose the right tools to secure your cluster. The primary goals of implementing GKE network security are workload isolation and secure multi-tenancy. To achieve these goals, you should apply the principles of least privilege, defense-in-depth, and use actionable data to inform your security decisions.

In Google Kubernetes Engine (GKE), applying the principle of least privilege to network traffic means restricting communication to only what is necessary for your applications to function. By default, the network within a GKE cluster is open, which means every Pod can communicate with every other Pod.

This document helps Operators, Networking specialists, and Security specialists understand and implement network security within GKE clusters. For more information about common roles and example tasks in Google Cloud, see Common GKE user roles and tasks.

Before reading this document, verify that you are familiar with the following:

  • GKE networking concepts: for an overview, see About GKE networking.
  • Kubernetes Pods, Services, and namespaces: these fundamental Kubernetes resources are central to defining network security policies. See the Kubernetes documentation.
  • The principle of least privilege: this security principle is a core concept applied throughout this document.

Goals of GKE network security

GKE network security policies provide fine-grained, Kubernetes-aware traffic control within your cluster. These policies are a critical element of your overall security strategy. To implement robust network security, consider these fundamental principles:

  • Least privilege: grant systems and services only the minimum privileges required to perform their functions. This principle reduces the potential impact of a compromise. Kubernetes network policies help you move from a default-open network to one where only necessary connections are allowed.
  • Defense in depth: layer multiple, independent security controls. A failure in one control does not lead to a total system compromise. For example, you use a network policy to isolate a database, even if the database itself requires authentication.
  • Actionable data: base security decisions on data. Threat modeling and risk assessment inform your security posture. Features like network policy logging provide the data to verify policies and detect potential breaches.

Choose a network security policy

To choose the right policy, identify the type and scope of the traffic you need to control.

Types of traffic

To choose the right policy, consider the source and destination of the traffic you want to manage:

  • Communication between Pods within the cluster: to control how microservices communicate with each other, use policies that operate on Pod labels and namespaces.

    • As an application developer, use the standard Kubernetes NetworkPolicy to define ingress and egress rules for your application within its namespace.
    • As a cluster administrator, use the CiliumClusterwideNetworkPolicy to enforce security guardrails that apply to the entire cluster. The deny rules in NetworkPolicy take precedence over the CiliumClusterwideNetworkPolicy allow rules.

  • Egress traffic from Pods to external services: to control egress traffic from Pods to external services based on domain names, use FQDNNetworkPolicy. This policy is useful when the IP addresses of external services are not static, because it automatically resolves and updates the allowed IP addresses based on DNS.

  • Encryption for all service-to-service traffic: to help ensure all communication between services is encrypted and authenticated, use a service mesh. Use Istio or Anthos Cloud Service Mesh to implement mutual TLS (mTLS), which automatically handles encryption.

Summary of policy choices

The following table summarizes which policy to use based on your security goal.

Goal Recommended policy
Control traffic between Pods by using labels and namespaces. Kubernetes NetworkPolicy
Control egress traffic to external services by domain name. FQDNNetworkPolicy
Encrypt and authenticate all service-to-service traffic. Istio or Anthos Cloud Service Mesh (for mTLS)
Enforce mandatory, cluster-wide rules as an administrator. CiliumClusterwideNetworkPolicy
Audit and log connections allowed or denied by policies. network policy logging (enabled for any policy)

Audit and troubleshoot network policies

After implementing network policies, verify that they work as expected and diagnose any connectivity issues. You can use Network Policy Logging as the primary tool for this.

When you enable network policy logging, GKE generates a log record in Cloud Logging for every connection that a network policy allows or denies. These logs are essential for performing security auditing and troubleshooting unexpected behavior. Reviewing these logs lets you see the concrete effects of your rules, confirming that legitimate traffic flows as expected and that unauthorized traffic is blocked.

What's next