Kubernetes and Cloud Native Security Associate (KCSA)

Kubernetes Cluster Component Security

Securing Container Networking

Containers in Kubernetes communicate over a flat, cluster-wide network by default. While this architecture simplifies connectivity, it can expose your workloads to various security threats. In this guide, we’ll walk through four essential strategies to tighten your cluster’s network security.

Kubernetes’s Flat Network Model

By default, Kubernetes implements a flat network where:

  • Each Pod receives a unique IP address.
  • Containers within the same Pod share network namespace, IP, and port space.
  • Pods communicate directly, without NAT.
  • DNS resolves Services to enable Pod-to-Service calls.
  • External traffic is routed through Ingress controllers or external LoadBalancers.

Warning

Running with an open, flat network model means any Pod can talk to any other Pod by default. Always apply security controls before deploying production workloads.

Network Security Focus Areas

Security AreaTooling/FeaturePurpose
Pod-to-Pod Traffic ControlNetwork PoliciesRestrict ingress/egress at the Pod level
Service-to-Service CommunicationService Mesh (Istio, Linkerd)Enforce mTLS, advanced routing, observability
Node-to-Node EncryptionCalico with IPsec / WireGuardEncrypt inter-node traffic
Workload IsolationNamespaces & Network PoliciesLimit blast radius through segment isolation

1. Restricting Pod Communication with Network Policies

By default, all Pod-to-Pod traffic is permitted. To establish a secure baseline, use a deny-by-default policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress: []
  egress: []

This policy blocks all incoming and outgoing traffic in the default namespace. You can then layer on additional policies to explicitly allow necessary connections.

Note

After applying a deny-all policy, define granular allow rules for DNS, API server access, and any other required services.


2. Service-to-Service Security with a Service Mesh

Deploying a service mesh such as Istio or Linkerd adds powerful features:

The image illustrates a service mesh architecture using Istio and Linkerd within a cluster, showing nodes, pods, and an NGINX controller for traffic management and observability. It highlights features like mutual TLS and traffic management.

  • Mutual TLS (mTLS) encrypts and authenticates service-to-service calls.
  • Fine-grained traffic management: retries, timeouts, and routing rules.
  • Built-in telemetry, metrics, and logs for full observability.

By enforcing mTLS, Istio can prevent man-in-the-middle attacks and ensure only authenticated services can communicate.


3. Encrypting Network Traffic Between Nodes

Protect data in transit at the network layer by enabling encryption with CNI plugins like Calico:

The image is a diagram illustrating encrypted network traffic within a cluster, showing nodes, pods, and the use of IPSec and WireGuard for security. It includes an NGINX Controller and highlights a network layer with secure and potentially insecure nodes.

  • Calico + IPsec: Encrypts all inter-node traffic without requiring additional hardware.
  • WireGuard: A lightweight, high-performance VPN alternative.

Configuring IPsec in Calico ensures confidentiality and integrity for pod networking across nodes.


4. Isolating Sensitive Workloads

Segregate critical applications into dedicated namespaces and apply strict policies to reduce lateral movement:

The image illustrates a Kubernetes cluster setup for isolating sensitive workloads, showing nodes, namespaces, and pods with an NGINX Controller managing the cluster.

By combining namespaces with network policies, you can limit which teams or services can communicate, containing any potential breach.


Summary

The image is a summary slide listing four key points about network policies and security measures for containers, including implementing network policies, using service meshes, encrypting traffic, and isolating workloads.

To recap:

  1. Define Network Policies to control Pod-level traffic.
  2. Deploy a Service Mesh for mTLS and advanced routing.
  3. Encrypt inter-node traffic with IPsec or WireGuard.
  4. Use Namespaces and strict policies to isolate workloads.

Watch Video

Watch video content

Previous
Securing Etcd