A security problem with KubeDNS
DNS，現代網路世界中的核心技術之一，其主要功能像是將 hostname 轉換成 IP 位址，讓使用者能不需要記住純數字的 IP 位址便能輕鬆的漫遊網路。如此重要的系統當然必須要有較為全面的安全性考量。
今天我們來說說 KubeDNS 作為早期 k8s 的標準配備所擁有的一項安全問題。
KubeDNS，Kubernetes 最早的 DNS Server，在 k8s v1.12 時正式被 CoreDNS 取代。這其中包括相當多的原因
- KubeDNS 是由三個 containers 所組成的，而 CoreDNS 卻只有一個¹
- Kube-dns 使用的 dnsmasq 是 single threaded C code，而 CoreDNS 則是multi-threaded Golang
- CoreDNS 的 negative caching 是預設的，KubeDNS卻不是
總結而言，這些導致 CoreDNS 效能相較 KubeDNS 要差上一些。
撇開功能與效能的差距，Security 也是非常重要的一個考量。
在現代軟體業中，為了更加快速的開發新功能，安全性往往會被人們忽略。而我們在適應 Microservices 的過程中又不得不與 container 們天天打交道。這樣的結果導致各式各樣的 attack 的讓我們不得不處處堤防。
IMO, the basic rule of container security is to run with least privilege.
說到 Least Privilege 最小權限原則，我們來看看作為一個 k8s 內部的 DNS Server，到底有哪些權限是必須的呢？
我們來看看 kOps，一個常見的 k8s operation 工具，是如何設定的CoreDNS的。簡單的說我們除了需要使用 DNS 常見的 port 53 以外，任何 Linux Capabilities 都是多餘的。（順帶一提其實 NET_BIND_ADMIN 也並非必須）
這裡我們其實可以了解到大多數 application 是不需要任何 Linux Capability 的。²
了解了上面的基本後我們來說說 KubeDNS 究竟存在著什麼問題呢？
kube-dns cannot run as non-root user #190³
是的！Container Security 中最基本的元則之一硬生生的被打破了。
KubeDNS 最為 k8s cluster 中極其容易被當作攻擊目標的 container 卻必須使用 UID 0 來運行。
這代表每當我們的 KubeDNS 被如入侵後，attacker 將能更加容易的在突破 container 並且控制我們的 k8s host。And attack follows on ! 從 DNS resolution下手再到 Node Control，在不知不覺的情況下你正在把自己客戶的重要資料免費送給有心人🤯。
所以如果你的 k8s cluster 還在使用 KubeDNS 作為 DNS Server 的話，在這裡建議可以考慮趕快換成 CoreDNS 喔！
這裡附上 CoreDNS Migration Guide ~
