Skip to main content

More Info:

Apply firewall rules that restrict traffic to and from GKE worker nodes based on tags, service accounts, and CIDR ranges. Tight firewalling limits lateral movement and unwanted access.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. Identify all node pools and instance groups
    • On any machine with gcloud configured, list GKE node pools and note the node locations:
    • List managed instance groups backing the node pools:
  2. Gather current worker node tags, service accounts, and networks
    • For each node pool MIG/instance name pattern, describe a representative node to see its tags, service accounts, and network:
  3. Inventory existing firewall rules affecting worker nodes
    • List all firewall rules in the relevant VPC network(s):
    • For each worker node tag or service account from step 2, filter rules that apply:
  4. Decide the minimal required traffic
    • Review which sources legitimately need to reach worker nodes (e.g., control-plane IPs, load balancer health checks, CI/CD CIDRs, on-prem CIDRs) and which egress from nodes is required (e.g., Google APIs, container registries, specific partner services).
    • Document allowed CIDR ranges, ports/protocols, and whether scoping by target tags or target service accounts is preferable for each node pool.
  5. Create or tighten firewall rules based on the decision
    • For each required traffic pattern, create least-privilege rules scoped by tags or service accounts (example template; replace placeholders):
    • Remove or lower-priority broad rules that unnecessarily allow 0.0.0.0/0 or wide port ranges to worker node tags/service accounts, ensuring you do not block required control-plane or health-check traffic.
  6. Verify and re-assess exposure
    • Re-list firewall rules and confirm workers are only covered by appropriately scoped rules:
    • Optionally, perform connectivity tests from expected sources and from disallowed networks to confirm access is correctly restricted.
kubectl cannot configure Google Cloud firewall rules or VPC networking; those changes must be made in the GCP console, via gcloud, or through IaC (e.g., Terraform) at the cloud provider level. Refer to the Manual Steps section for guidance on reviewing and implementing appropriate firewall rules for GKE worker nodes.
How to interpret the output (what indicates a problem)Review the report for each cluster and flag cases like:
  • Nodes with tags or service accounts that are not used by any restrictive firewall rules (no targetTags / targetServiceAccounts match), meaning they rely only on wide-open network rules.
  • Firewall rules with:
    • Very broad sourceRanges (e.g. 0.0.0.0/0 or full private ranges) reaching node tags/service accounts.
    • No targetTags or targetServiceAccounts (applies to all instances in the network).
    • Allowed protocols/ports that are unnecessary or very broad (e.g. tcp:1-65535, all).
  • Absence of dedicated rules that:
    • Limit inbound access to nodes only from known admin/source CIDRs or specific service accounts/tags.
    • Limit east‑west (lateral) traffic between node pools, environments, or workloads where isolation is desired.
Use these findings to manually design tighter firewall rules with gcloud compute firewall-rules create as per the benchmark remediation.