＃容器周報 #K8s資安 #DevSecOps #Testcontainers

你家K8s安全由誰來顧？

容器資安責任的歸屬仍非常分歧，27%企業指派給DevOps，21%則由維運團隊負責，另有18%企業則交給資安團隊，只有18%企業有專門的DevSecOps團隊，但超過7成企業都認同，自家DevOps和資安團隊必需要有一套安全協作的方式，才能進一步落實容器的安全。

7/9~7/15 精選容器新聞
✅紅帽公布最新K8s安全報告，最常見的資安事件是配置出錯
✅AtomicJar計畫把開源的Java容器單元測試工具Testcontainers變成新服務
✅K8s和雲端維運大調查，近1成金融業擁抱K8s，熱度僅次科技業
✅經過漫長的5年，runC終於釋出了1.0版
✅強化Linux容器安全布局，Sophos併購容器即時偵測工具Capsule8
✅IBM持續擴充顧問服務部門戰力，新併購容器服務商BoxBoat
✅雲達科技和5G應用自動化平臺商Robin.io聯手，要讓電信商靠K8s變成雲端原生平臺商

更多內容請打開
https://www.ithome.com.tw/news/145716

今天這篇文章用來介紹 docker 20.10 所帶來的改變，就算 kuberetes 未來不再預設使用 docker 作為其 CRI，但是對於本地開發者來說， docker 還是個短期不太可能淘汰的工具，所以適時的理解最新的一些變化也是不可或缺的一部分

1. Rootless 從過去的實驗性質到全面支援

自從 runc 這個 container runtime 支援 cgroupv2 之後，已經可以透過 rootless 來創造符合 OCI 標準的容器，因此 docker 也可以順便藉由這個過程一併支持 rootless 的環境

2. Logging drivers

過往大家可能比較少會去關注或是修改 docker logging 的輸出方式，比較常見的是直接基於預設的情況去使用，而有部分的解決方案可能會特別修改成 syslog 等不同方式

而 20.10 所做的事情就是強化整體的使用習慣，讓你不管底層是使用何種 logging driver，你都可以透過 docker logs 的方式去閱讀這些資訊

3. OS support
20.10 開始支援 Ubuntu 20.10, Fedora 33 以及 CentOS8

4. CLI improvements

docker CLI 一直持續改進與強化，移除沒用的功能同時也針對一些常見功能加入一些參數，譬如
1. docker push 與 docker pull 的概念一致，預設情況下，如果不給 tag 就會幫忙帶入 latest 進去
2. docker exec 可以透過事先撰寫檔案來一口氣傳入大量的環境變數

https://towardsdatascience.com/whats-new-in-docker-20-10-fd1de1216c0

這是一篇幻想文，幻想如果你可以重新設計 Kubernetes，你會希望有什麼樣的改動。也因為是幻想文，所以以下所提的東西不一定真的可以實作，也沒有考慮實作上可能會有什麼困難。原文非常的長，所以這邊就稍微列出一些內容

# 前提
作者(David Anderson, MetalLB 的主要貢獻者)認為 Kubernetes 真的很複雜，從 MetalLB 的開發經驗來看，幾乎無法開發出一個永遠不會壞且與 k8s 整合的軟體。
k8s 發展快速，一些不相容的修改也很難除錯，往往導致這些整合應用程式一起壞掉。
此外，作者使用 GKE 的經驗讓他覺得就算是這些k8s專家，也很難大規模環境中平安順利的使用 k8s.

作者認為 k8s 就像是管理平台內的 c++，功能非常強大，什麼都可以做，但是它會一直傷害你，直到你奉獻餘生該領域內。
作者期盼有一天，可以出現一個像是 go 語言的管理平台，簡單，優雅，容易學習

接下來就來看一下如果時光倒流，作者會希望 k8s 有哪些功能

# Mutable Pod
不像其他的資源一樣， Pod 這個資源基本上是不能修改的，有任何的更動都需要先刪除，後重新部署這樣兩步走來處理。
作者希望可以有一種 Pod 是可以支援即時修改的。
舉例來說，我透過 kubectl edit 修改了 Pod Image，然後只要透過 SIGTERM 送給 Runc 底層容器，然後當該 Container 被重啟，就會使用新的設定。這一切的發生都在同一個 Pod 的資源內，而不是重新產生一個新的 Pod

# Version control all the things
當 Pod 可以修正後，下一個作者想要的功能就是基於 Pod 本身的 Rollback。這意味希望叢集內可以有這些資訊可以去紀錄每次的變化

為了實現這個功能，可能每個節點上面也要去紀錄過往的所有 image 版本資訊，並且加上 GC 等概念來清除過期或是太舊的內容

# Replace Deployment with PinnedDeployment
相對於 Deployment， PinnedDeployment 最大的改動就是一個 Deployment 內可以同時維護兩個版本的 Pod。

舉例來說，我今天要將 Nginx 從 1.16 升級到 1.17，我可以透過 PinnedDeployment 去部署 Nginx，其中 1.16 佔了 60% ，而新版本 1.17 佔了 40%。

當一切轉移都沒有問題後，可以逐漸地將新版本的比例遷移到 100% 來達成真正的移轉。
原生的 Deployment 要達到這個功能就要創建兩個 Deployment 的物件來達到這個需求。

# IPv6 only, mostly
作者期望能的話，想要把 k8s networking 內的東西全部移除，什麼 overlay network, serivce, CNI, kube-proxy 通通移除掉。

k8s 全面配置 IPv6，而且也只有 IPv6，通常來說你的 LAN 都會有 /64 這麼多的地址可以分配 IPv6，這個數量多到你根本不可能用完 (2^64)。
也因為都有 public IPv6 的緣故，所有的存取都採用 Routing 的方式，封裝之類的玩法也不需要了。

文章內還提了很多東西，譬如說如果今天真的需要導入 IPv4 於這個純 IPv6 的系統上，可以怎麼做，如何設計 NAT64 等，算是非常有趣的想法

# Security is yes
作者認為安全性方面要最大強化，預設情況下要開啟 AppArmor, seccomp profile 等控管機制，同時也要全面禁止用 Root 來運行容器， 基本上就是用非常嚴格的方式來設定安全性方面的規則。

目前 Kubernetes 內的資源， Pod Security Policy 非常類似作者想要完成的東西，通過這種機制確保所有部署的 Pod 都會符合這些條件。唯一美中不足的是 Pod Security Policy 也不是預設就有的規則。

# gVisor? Firecracker?
從安全性考量出發，是否預設改使用 gVisor 或是 Firecracker 這類型的 OCI Runtime 而非 Runc，同時搭配上述的各種安全性條件來打造非常嚴苛的運行環境

# VMs as primitives
是否可以讓 kubernetes 同時管理 container 以及 virtual machine，也許就會像是將 kubevirt 變成一個內建的功能，讓 kubernetes 更加靈活的使用

除了上面之外，文章內還有許多其他的想法，但是內容都滿長的，如果有興趣的可以點選下列連結參考看看
https://blog.dave.tf/post/new-kubernetes/