Protecting an Entire GKE Cluster With ClusterNetworkPolicy

If network policies block DNS traffic, the application may fail before it ever reaches its intended destination.

A typical architecture looks like:

Application Pod
      |
      | DNS request
      v
Cluster DNS
      |
      | IP address
      v
Application destination

When testing restrictive policies, verify DNS explicitly.

Protect Sensitive Namespaces

Some namespaces should have stronger network controls than ordinary application namespaces.

Examples might include:

security
platform
payments
identity
database

The exact names are organization-specific.

The important concept is that not every workload should have equal network access.

For example, an application may need access to a payment API but should not be allowed to communicate directly with administrative infrastructure.

A cluster-level policy can help establish these broader boundaries.

Separate Ingress and Egress Requirements

Network traffic has two directions.

Ingress means traffic entering a workload.

Egress means traffic leaving a workload.

For example:

Frontend -> API

is ingress traffic from the API's perspective.

While:

API -> Database

is egress traffic from the API's perspective.

Security designs should consider both directions.

A workload that is protected from unwanted incoming connections may still be able to initiate connections to many external destinations.

That can be a security problem if a compromised workload attempts to contact an external command-and-control service or exfiltrate data.

Egress Restrictions Are Particularly Important

Many Kubernetes environments focus heavily on incoming traffic.

Outgoing traffic can be just as important.

Consider a compromised pod:

Internet
   ^
   |
   | Unauthorized data transfer
   |
Compromised Pod

If the pod can freely communicate with the internet, an attacker may have more options.

An egress policy can reduce the number of destinations available to workloads.

For example, a backend service might only need access to:

Database
Payment API
Object Storage
DNS
Monitoring

Allowing everything else may provide unnecessary network access.

Be Careful With External APIs

Modern applications frequently call external services.

Examples include:

• Payment providers.
• Email services.
• AI APIs.
• Identity providers.
• SaaS platforms.
• Package repositories.

If an egress policy blocks these destinations, the application may fail.

The solution is not to allow all internet traffic automatically.

Instead, identify the required external dependencies and decide how they should be accessed.

Where possible, use stable service endpoints and controlled egress architecture rather than broad unrestricted internet access.

Cluster-Level Policies Should Not Hide Application Responsibilities

A platform team should not attempt to encode every application rule into one giant cluster policy.

For example, the application team may know that:

frontend -> API

is required, while the security team knows that:

all workloads -> sensitive admin subnet

must be blocked.

These concerns should remain separated.

A good division of responsibility is:

Platform/Security
    |
    +-- Cluster-wide security baseline
    +-- Sensitive network restrictions
    +-- Organization-wide requirements

Application Team
    |
    +-- Application communication
    +-- Service dependencies
    +-- Namespace-level rules

This makes policies easier to maintain.

Test Policies With a Representative Workload

A policy that works for one namespace may fail elsewhere.

Before production rollout, test:

Frontend
API
Worker
Database client
Monitoring
Ingress
DNS
External API calls

For each workload, test both allowed and denied traffic.

For example:

Expected:
Frontend -> API       Allowed
API -> Database       Allowed
Frontend -> Database  Denied
Worker -> API         Allowed
Worker -> Admin       Denied

Negative tests are especially important.

A policy is not successful only because legitimate traffic works.

It also needs to demonstrate that prohibited traffic is actually blocked.

Roll Out in Stages

Cluster-level network changes should generally be introduced gradually.

A practical rollout can look like this:

Stage 1: Inventory

Identify namespaces, workloads, services, external dependencies, and network paths.

Stage 2: Test Environment

Apply the policy to a non-production cluster with similar architecture.

Stage 3: Limited Production Scope

Start with a small group of workloads where the expected traffic is well understood.

Stage 4: Monitor

Watch application errors, network drops, DNS failures, and service health.

Stage 5: Expand

Apply the policy to additional namespaces or workload groups.

Stage 6: Review

Remove temporary exceptions and document permanent rules.

This is safer than applying a restrictive cluster-wide policy to every workload immediately.

Troubleshooting a Blocked Application

When an application suddenly stops communicating after a policy change, troubleshoot from the application outward.

A useful sequence is:

Application error
      |
      v
Is DNS working?
      |
      v
Is the destination reachable?
      |
      v
Is the port allowed?
      |
      v
Is the source workload selected correctly?
      |
      v
Is another policy blocking traffic?
      |
      v
Is the destination itself healthy?

This prevents random policy changes.

For example, if an API reports:

Connection timeout

do not immediately allow all traffic.

First determine whether the failure is DNS, routing, port access, policy selection, or application health.

Look at Policy Selection Carefully

Kubernetes policies depend heavily on selectors.

A selector that matches too many workloads can create unexpected restrictions.

A selector that matches nothing can create a false sense of security.

For example, changing:

app: payments

to:

tier: backend

may suddenly include many unrelated workloads.

Always verify which pods are actually selected after policy changes.

Avoid Giant Policy Files

A single massive cluster policy can become difficult to review.

When everything is combined into one configuration:

DNS rules
Ingress rules
Egress rules
Monitoring rules
Security rules
Application exceptions
Temporary exceptions

it becomes harder to understand why a specific rule exists.

Prefer logical separation where supported and keep comments and documentation close to the policy definition.

The goal is that another engineer should be able to understand the security intent without reconstructing the entire cluster.

Manage Policies as Code

Network security configuration should generally be managed through the same change-management process as application infrastructure.

A repository might contain:

network-policy/
    cluster/
        baseline.yaml
        restricted-egress.yaml
        sensitive-workloads.yaml
    namespaces/
        payments.yaml
        orders.yaml

Changes can then be reviewed before deployment.

This provides:

• Version history.
• Code review.
• Reproducible deployment.
• Easier rollback.
• Clear ownership.
• Auditability.

Manual changes through production consoles are harder to track and reproduce.

Common Mistakes

Applying Deny Rules Before Understanding Dependencies

A policy can break DNS, monitoring, ingress, or external API access.

Map dependencies first.

Assuming Namespace Policies Provide Complete Cluster Security

Application-level policies do not automatically establish every organization-wide network control.

Use cluster-level controls where centralized enforcement is required.

Using Pod IP Addresses

Pod addresses change.

Prefer workload identity and labels where supported.

Blocking All Egress

Applications often require external APIs, DNS, package services, storage endpoints, or other dependencies.

Restrict egress based on actual requirements.

Forgetting DNS

A working application can still fail if it cannot resolve service names.

Always include DNS in network testing.

Creating One Giant Policy

Overly broad configuration becomes difficult to review and troubleshoot.

Keep rules organized around clear security goals.

Testing Only Successful Traffic

Always test traffic that should be blocked.

Otherwise, an overly permissive policy can appear successful.

Advantages and Disadvantages

Advantages

• Centralized cluster-level network enforcement.
• Reduced dependency on every team implementing the same baseline.
• Better protection for sensitive workloads.
• More consistent security controls.
• Easier enforcement of organization-wide requirements.
• Useful for controlling unwanted east-west traffic.
• Can complement namespace-level policies.

Disadvantages

• Incorrect rules can affect many applications.
• Troubleshooting becomes more important.
• Requires accurate dependency mapping.
• Egress restrictions can be difficult in complex environments.
• Policy interactions can become complicated.
• Poorly designed selectors can create unexpected behavior.

The main tradeoff is centralized control versus blast radius. A cluster-wide policy can solve security problems that are difficult to manage individually, but a mistake can affect many workloads at the same time.

Production Checklist

Before enabling ClusterNetworkPolicy in a production GKE cluster, verify:

• The GKE networking configuration supports the required policy behavior.
• Cluster-level security requirements are documented.
• Application traffic dependencies have been inventoried.
• DNS traffic has been tested.
• Ingress traffic has been tested.
• Required egress destinations have been identified.
• Sensitive workloads have stronger network boundaries where appropriate.
• Workload selectors have been reviewed.
• Pod IP addresses are not being used as permanent identities.
• Both allowed and denied traffic have been tested.
• Policies are stored as code.
• Changes go through code review.
• Monitoring is available for blocked traffic and application failures.
• Rollback procedures have been tested.
• Temporary exceptions have owners and expiration dates.
• Production rollout is staged rather than performed blindly across the entire cluster.

Summary

ClusterNetworkPolicy gives GKE platform and security teams a way to enforce network controls at the cluster level instead of depending entirely on individual namespaces and application teams.

It is particularly useful for establishing security boundaries, restricting sensitive network paths, controlling east-west communication, and creating a consistent baseline across workloads.

The safest design is not to start with a large deny rule. Start by understanding how applications communicate. Document DNS, ingress, egress, database, monitoring, storage, and external API dependencies. Then create policies that enforce the required boundaries without blocking legitimate traffic.

Use ClusterNetworkPolicy together with application-level NetworkPolicy rather than treating it as a replacement for every workload-specific rule. Keep policies understandable, manage them as code, test both allowed and denied traffic, and roll them out gradually.

A cluster-wide network policy is most effective when it expresses a small number of clear security boundaries that remain stable as applications and pods change. The goal is not simply to block more traffic. The goal is to make the network behavior of the cluster predictable, intentional, and easier to secure.