2024-03-21 13:27:24 +00:00
|
|
|
---
|
|
|
|
title: Stop leaking Kubernetes service information via DNS
|
|
|
|
weight: 1
|
2024-03-25 12:45:10 +00:00
|
|
|
tags:
|
|
|
|
- platform
|
|
|
|
- security
|
|
|
|
- network
|
2024-03-21 13:27:24 +00:00
|
|
|
---
|
|
|
|
|
|
|
|
A talk by Google and Ivanti.
|
|
|
|
|
|
|
|
## Background
|
|
|
|
|
2024-03-26 14:09:33 +00:00
|
|
|
* RBAC is there to limit information access and control
|
|
|
|
* RBAC can be used to avoid interference in shared envs
|
2024-03-21 13:27:24 +00:00
|
|
|
* DNS is not really applicable when it comes to RBAC
|
|
|
|
|
|
|
|
### DNS in Kubernetes
|
|
|
|
|
|
|
|
* DNS Info is always public -> No auth
|
|
|
|
* Services are exposed to all clients
|
|
|
|
|
|
|
|
## Isolation and Clusters
|
|
|
|
|
|
|
|
### Just don't share
|
|
|
|
|
|
|
|
* Specially for smaller, high growth companies with infinite VC money
|
|
|
|
* Just give everyone their own cluster -> Problem solved
|
2024-03-26 14:09:33 +00:00
|
|
|
* Smaller (<1000) typically use many small clusters
|
2024-03-21 13:27:24 +00:00
|
|
|
|
|
|
|
### Shared Clusters
|
|
|
|
|
2024-03-26 14:09:33 +00:00
|
|
|
* Becomes important when cost is a question and engineers don't have any platform knowledge
|
2024-03-21 13:27:24 +00:00
|
|
|
* A dedicated kube team can optimize both hardware and deliver updates fast -> Increased productivity by utilizing specialists
|
|
|
|
* Problem: Noisy neighbors by leaky DNS
|
|
|
|
|
|
|
|
## Leaks (demo)
|
|
|
|
|
|
|
|
### Base scenario
|
|
|
|
|
|
|
|
* Cluster with a bunch of deployments and services
|
|
|
|
* Creating a simple pod results in binding to default RBAC -> No access to anything
|
|
|
|
* Querying DNS info (aka services) still leaks everything (namespaces, services)
|
|
|
|
|
|
|
|
### Leak mechanics
|
|
|
|
|
|
|
|
* Leaks are based on the `<service>.<nemspace>.<svc>.cluster.local` pattern
|
2024-03-26 14:09:33 +00:00
|
|
|
* You can also just reverse lookup the entire service CIDR
|
2024-03-21 13:27:24 +00:00
|
|
|
* SRV records get created for each service including the service ports
|
|
|
|
|
|
|
|
## Fix the leak
|
|
|
|
|
|
|
|
### CoreDNS Firewall Plugin
|
|
|
|
|
2024-03-26 14:09:33 +00:00
|
|
|
* External plugin provided by the CoreDNS team
|
2024-03-21 13:27:24 +00:00
|
|
|
* Expression engine built-in with support for external policy engines
|
|
|
|
|
|
|
|
```mermaid
|
|
|
|
flowchart LR
|
|
|
|
req-->metadata
|
|
|
|
metadata-->firewall
|
|
|
|
firewall-->kube
|
|
|
|
kube-->|Adds namespace/clientnamespace metadata|firewall
|
|
|
|
firewall-->|send nxdomain|metadata
|
|
|
|
metadata-->res
|
|
|
|
```
|
|
|
|
|
|
|
|
### Demo
|
|
|
|
|
2024-03-26 14:09:33 +00:00
|
|
|
* Firewall rule that only allows queries from the same namespace, `kube-system` or `default`
|
2024-03-21 13:27:24 +00:00
|
|
|
* Every other cross-namespace request gets blocked
|
2024-03-26 14:09:33 +00:00
|
|
|
* Same SVC requests from before now return `NXDOMAIN`
|
2024-03-21 13:27:24 +00:00
|
|
|
|
|
|
|
### Why is this a plugin and not default?
|
|
|
|
|
|
|
|
* Requires `pods verified` mode -> Puts the watch on pods and only returns a query result if the pod actually exists
|
2024-03-26 14:09:33 +00:00
|
|
|
* Puts a watch on all pods -> higher API load and CoreDNS memory usage
|
2024-03-21 13:27:24 +00:00
|
|
|
* Potential race conditions with initial lookups in larger clusters -> Alternative is to fail open (not really secure)
|
|
|
|
|
|
|
|
### Per tenant DNS
|
|
|
|
|
2024-03-26 14:09:33 +00:00
|
|
|
* Just run a CoreDNS instance for each tenant
|
|
|
|
* Use a mutating webhook to inject the right DNS into each pod
|
2024-03-21 13:27:24 +00:00
|
|
|
* Pro: No more pods verified -> Aka no more constant watch
|
2024-03-26 14:09:33 +00:00
|
|
|
* Limitation: Platform services still need a central CoreDNS
|