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
MediumAddress
SecurityCompliance Standards
- CIS GKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
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:
- On any machine with gcloud configured, list GKE node pools and note the node locations:
-
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:
- For each node pool MIG/instance name pattern, describe a representative node to see its tags, service accounts, and network:
-
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:
- List all firewall rules in the relevant VPC network(s):
-
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.
-
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/0or wide port ranges to worker node tags/service accounts, ensuring you do not block required control-plane or health-check traffic.
- For each required traffic pattern, create least-privilege rules scoped by tags or service accounts (example template; replace placeholders):
-
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.
- Re-list firewall rules and confirm workers are only covered by appropriately scoped rules:
Using kubectl
Using kubectl
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.Automation
Automation
- Nodes with tags or service accounts that are not used by any restrictive firewall rules (no
targetTags/targetServiceAccountsmatch), meaning they rely only on wide-open network rules. - Firewall rules with:
- Very broad
sourceRanges(e.g.0.0.0.0/0or full private ranges) reaching node tags/service accounts. - No
targetTagsortargetServiceAccounts(applies to all instances in the network). - Allowed protocols/ports that are unnecessary or very broad (e.g.
tcp:1-65535,all).
- Very broad
- 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.
gcloud compute firewall-rules create as per the benchmark remediation.
