
## Introduction

DNS spoofing in Kubernetes remains a critical threat, enabling attackers to redirect traffic, intercept data, or disrupt services. This article explores how such attacks occur and outlines strategies to prevent them.

## K8s networking

In Kubernetes, pods communicate over a virtual bridge (commonly cbr0) that connects all pods on a node. The cbr0 can also handle ARP (Address Resolution Protocol) resolution. When an incoming packet arrives at cbr0, it can resolve the destination MAC address using ARP.

CoreDNS, running as a pod, handles DNS resolution for the cluster. Each pod's /etc/resolv.conf typically points to the ClusterIP of the CoreDNS service, often 10.96.0.10. Kube-proxy sets up iptables rules to route DNS requests to the appropriate CoreDNS pod.

In essence, this is how pods communicate with each other on the same node. It’s also how Docker works and is the default for K8s.

## Understanding How DNS Works Inside Kubernetes

Let’s break down how DNS requests flow in a Kubernetes cluster — especially how pods talk to CoreDNS.

Each pod in your cluster is set up to use CoreDNS (or kube-dns) as its default DNS server. CoreDNS itself runs as a pod, typically inside the kube-system namespace. You can have multiple CoreDNS pods for HA, but for simplicity, let’s assume one for now.

### How Does a Pod Know Where CoreDNS Lives?

When a pod is created, Kubernetes injects a /etc/resolv.conf file like this:

```bash
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
```

That 10.96.0.10 is the ClusterIP of the kube-dns Service. It’s a stable VIP (virtual IP) used for all DNS requests inside the cluster. CoreDNS pods sit behind this service and receive DNS queries forwarded by kube-proxy using iptables DNAT rules.

### How the Flow Works

1. Your pod makes a DNS request (e.g. nslookup my-service)

2. It hits the VIP (10.96.0.10)

3. kube-proxy rewrites the packet (DNAT) to one of the actual CoreDNS pod IPs

4. CoreDNS checks:
    - Is this a cluster service/pod/etc? → resolve it locally
    - Else → forward to upstream DNS (e.g. Google DNS)

This behavior is defined by the pod’s dnsPolicy, which is set to ClusterFirst by default.

### From kubelet's DNS handling logic:

For a pod with DNSClusterFirst policy,
the cluster DNS server is the only nameserver configured.
CoreDNS will forward queries to upstream nameservers
if it can’t resolve them locally.

### 🧩 Key Point

A pod doesn’t talk to CoreDNS directly by IP — it talks to a Service VIP that’s transparently routed to a pod. This abstraction makes DNS scalable and fault-tolerant, but also opens the door for network-layer attacks like DNS spoofing if a pod has raw socket access.

## The Attack Vector: ARP Spoofing via NET_RAW

By default, Kubernetes grants pods the NET_RAW capability, allowing them to craft raw packets, including ARP messages. An attacker can exploit this to perform ARP spoofing, tricking the network into sending DNS requests to a malicious pod instead of the legitimate CoreDNS pod.

### Steps to Exploit

1. Identify CoreDNS Pod IP: Send a DNS request and observe the source IP of the response to determine the CoreDNS pod's IP.

2. Determine Bridge IP and MAC: Use tools like scapy to send packets with TTL=1 to an external IP, capturing the bridge's IP and MAC address.

3. Send Fake ARP Replies: Continuously send ARP replies to the bridge, associating the CoreDNS IP with the attacker's MAC address.

4. Intercept DNS Requests: Run a DNS proxy in the malicious pod to handle intercepted DNS requests, forwarding them to the real CoreDNS pod or spoofing responses as desired.

This method allows the attacker to intercept and manipulate DNS traffic, potentially redirecting services to malicious endpoints.

## Mitigation Strategies

1. Drop NET_RAW Capability

Modify pod security contexts to drop the NET_RAW capability, preventing pods from crafting raw packets.

```yaml
securityContext:
  capabilities:
    drop:
      - NET_RAW
```

1. Implement Network Policies
Use Kubernetes NetworkPolicies to restrict pod communication, ensuring only authorized pods can communicate with CoreDNS.

1. Isolate CoreDNS Pods
Schedule CoreDNS pods on dedicated nodes and restrict access to these nodes, reducing the risk of compromise.

1. Monitor and Audit Changes
Continuously monitor and audit changes to the CoreDNS ConfigMap and related resources to detect unauthorized modifications promptly.

## Conclusion

DNS spoofing remains a common threat in Kubernetes environments. By understanding the attack vectors and implementing robust security measures, organisations can safeguard their clusters against such threats.


Posts tagged with: coredns