Title: 分散式系統的基本理論 CAP 的介紹
Source: https://www.educative.io/blog/what-is-cap-theorem#whatiscaptheorem


學習分散式系統的人都必須要理解的 CAP 定理，該定理描述的是 C(Consistent), A(Availability), P(Partition Tolerance) 三者並不可能同時滿足，因此會根據設計情況產生出
CA, CP, AP 等三種不同架構的設計。

Consistent: 講求的是一制性，要求分散式系統中任何時間點去詢問任何節點都可以問到一致的最新資料，所有資料都是一致的
Availability: 系統任何時間都要維持可用性，意味不論分散式環境中節點狀況如何，每個每個請求都可以得到一個非錯誤的回應，但是並沒有保證獲取的資料一定是最新的。
Partition tolerance: 當網路出現問題導致節點分區(分區意味節點之間沒有辦法透過網路溝通)，這種情況下整個系統依然要可以運作

根據定理，這三個特性沒有辦法同時滿足，因此設計系統時必定要有取捨。通常 CA 架構比較不會被討論是因為其捨棄了 P 的概念，沒有辦法處理網路的情況多半不會是分散式系統架構，更像是單節點的服務，因此更多的聚焦都是 AP 與 CP 兩種不同設計。

文章中雖然有依照資料庫類型去列舉是 AP 還是 CP，不過實務上的設計並不是如此的非黑即白，更多時候會有一些設定的彈性來處理 C&A 資料的關係，如果對於這類型有興趣也可以參考這篇文章
https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html

Title: Terraform/OpenTofu 分家後的開源貢獻體驗
Source: https://medium.com/@andrewhertog/contributing-to-terraform-vs-opentofu-26779d480c7f

如果有關注 IaC(infrastructure as a code) 的人可能最近幾個月有關注到 Terraform 因為授權改變而引發的一系列事件

Terraform 本身是由 HashiCorp 公司開發與維護，其架構與使用性吸引了大量的開發者與平台貢獻者，縱使有AWS CDK, Pulumi 等其他解決方案並存，Terraform 依舊還是所有人踏入 IaC 世界的首選。

然而從 Terraform v1.6 之後，這個選擇將會面臨兩個分歧點，該繼續使用由 HashiCorp 所維護的 Terraform 或是目前已經掛在 Linux Foundation 底下的分支 OpenTofu.

有鑒於 HashiCorp 於 1.6 版本後引入的授權機制，不少基於 Terraform 去搭建 SaaS 等商業收費的公司全部預料都將受到影響，公司的生財工具無法繼續免費使用而必須要開始付費給 HashiCorp, 因此便開始組隊，號召要求 HashiCorp 繼續保持開放開源免費。最後的結果就是 OpenTofu 這個完全基於 Terraform 1.5 分之出來的全新專案，並且未來將會完全獨立於 Terraform 的發展，功能/用法等未來應該會逐漸有更多的分歧

本篇文章是作者基於自己的貢獻經驗分享講相同的錯誤修正提交到 Terraform 與 OpenTofu 兩個不同社群的過程與體驗
以作者的經驗來說， terraform 的溝通緩慢不順且發生令人不能接受的事情（merge 不討論不通知，直接吃走 credit)
。而 OpenTofu 方面則有更多的討論與互動，對開源貢獻者來說體驗更好，也會更吸引開發者繼續貢獻與支持。

未來怎麼走不清楚，也不知道到底誰會贏誰，但是目前可以確定的是使用者當升級到1.6版本時勢必要開始思索授權是否會造成影響，以及 OpenTofu 是否可以變成替代品

Koordinator 是一套基於 QoS 的 Kubernetes scheduler 解決方案，目標是基於更細膩的 QoS 設定來處理服務部署與調度的問題。
預設的 Kubernetes Scheduler QoS 針對的比較是踢除時以及相關運算資源的比較，而 Koordinator 則加強關於資源部署的考量，譬如

考慮當前節點的資源用量
考慮 Colocation 的需求
提供基於 NUMA 需求的部署，讓應用程式可以更有效地去使用 CPU 資源
提供比社群版本更強大的 Descheduler

https://github.com/koordinator-sh/koordinator

Kubectl exec 與 Kubectl attach 的差異

https://medium.com/@adil/what-is-the-difference-between-kubectl-attach-and-kubectl-exec-148dab1e2aa3

常用 kubectl 指令的人鐵定對 kubectl exec 不陌生，該指令可以讓我們進入容器內去執行一些指令進行一些額外除錯，但是某一些應用程式本身運行時也會提供一些互動介面去進行操作，這種情況就不能使用 exec 來處理，反而要改使用 attach 來進行互動。
透過 kubectl attach 就可以直接掛到正在運行的 Process 上，當然使用上也要注意 TTY 的相關設定

Distroless base image 的好壞處

https://medium.com/@8grams/distroless-using-minimal-container-image-for-kubernetes-workload-9b143f83bd10

容器化的世界中一個非常重要的議題就是底層 image 的選擇，本篇文章仔細介紹 Distroless 的優缺點，其特性就是盡量減少無關之元件，相關特性有

1. OS 不提供任何 package manager
2. 只安裝真正需要的東西，不需要的都不安裝
3. 由於安裝的東西非常少，所以安全性方面會相對安全，需要專注處理資安/CVE的元件比較少
4. 連基本的 shell 存取都不安裝，因此發生問題時攻擊方也不能進入shell去執行相關指令

文章內有舉出幾個跟 Alpine 的比較，但是比較可惜的是沒有提到 Alpine 早年的各種 DNS 雷包問題

如何於 Kubernetes 實作 Topology-Aware Routing 讓彼此關聯服務的延遲性更低

https://medium.com/itnext/controlling-kubernetes-traffic-with-topology-aware-routing-9b1d51a43bd7

Kubernetes 於 1.23 後就正式 Beta 名為 Topology Aware Hints(已於 1.27 改名為 Topology Aware Routing) 的功能，以 ClusterIP 類型來說，目前有 InternalTrafficPolicy 可以設定成 Cluster/Local 兩者類型，然而這兩種類別不夠細膩。
本功能的目的是希望能夠以 Topology 作為轉發目標的選擇，這部分對於雲端使用者來說尤為重要，特別是某些雲端業者會針對跨 AZ(Available Zone)的流量進行收費，因此如果可以透過此功能去確保勁量將流量打到同 AZ 內的服務的話，不但可以省錢同時也可以有更低的 Latency。
至於 Topology 的定義則是由 label 去定義的，所以地端使用者也可以自行基於 Rack, Room…等實體類型去定義所謂的 Topology，透過此機制來調整轉發的選擇。
另外該機制本身也有所謂的檢查機制，若檢查機制沒有通過，則封包轉發就會退回最預設的模式，所以也不用擔心封包會因此被丟掉。

Cloudflare 探討轉移到 tcmalloc 對 Multithreading 應用程式記憶體控管帶來的好處

https://blog.cloudflare.com/the-effect-of-switching-to-tcmalloc-on-rocksdb-memory-use/

本篇文章探討了 Cloudflare 觀察到應用程式進行架構轉移後造成的記憶體用量暴增的情況，文章非常仔細的探討 Glibc Malloc 的實作原理，從 Arena, Chunk 等邏輯講解得非常清楚，也點出為什麼 Malloc 對於 Multithread 情境下很容易造成記憶體破碎的情形，最終導致浪費一堆用不到的記憶體(跟 OS 要一堆記憶體，實際上用到的非常少，更多記憶體就是被要來浪費，但是又沒有辦法歸還給 OS)

後半部分則是從 tcmalloc 出發介紹架構，其設計本身就是對 Multithread 的架構設計，因此使用上更能夠重複使用記憶體避免浪費，藉由簡單的切換就能夠讓應用程式
所需要的記憶體數量大幅減少，以 Cloudflare 的應用程式來說，整整減少了 2.5 倍。

Kubernetes 1.28 swap 支援進入 Beta 階段
https://kubernetes.io/blog/2023/08/24/swap-linux-beta/

由於 Memory Limit 實作的複雜度， Kubernetes 一開始就要求所有節點不能開啟 swap 這種使用硬碟空間暫代 Memory 的機制，然而某些使用情境下還是會希望有 swap 的支援，譬如
1. cgroupv2 實作更多關於 memory 的控制，然而部分的控制需要搭配 swap 才可以使用
2. 一些長期運行的 Java 應用程式可以透過 swap 獲得更好的效能
3. 對於某些會瞬間要暴增 memory 用量的應用程式，透過 swap 可以短暫提供足夠的 memory 來使用而不需要透過 resource 給予過多用不到的容量
4. ...etc

因此 1.22 後正式推出 alphe 階段的 swap 支援，而 1.28 則經歷不少功能改善與問題修復，正式邁入 beta 支援。
支援 swap 的精神就如同 Kubernetes 的一貫設計一樣，提供工具與方式，讓平台使用人員自己抉擇要不要使用，而非強硬寫死禁止使用。

五個分散式架構下的設計模式
https://www.educative.io/blog/distributed-system-design-patterns#load-balance

本文探討分散式架構下常見的幾種設計模式，每個設計模式都有期優缺點以及適合的場景，因此理解這些集結眾人之力的設計模式更多時候是學習眾人的經驗，減少踩雷的冤枉路，但是也要避免盡信書相信硬要把某設計模式套用到眼下所有情境。

文章介紹的五種設計模式分別為
1. Command and Query Responsibility Segrgation (CQRS)
Command 代表會改變系統狀態但是不會得到回傳的操作，而 Query 則是不會改變狀態但是會得到回傳值得操作。
大抵上可想像成讀寫分離的架構，其可以簡化整個系統的操作，但是讀寫之間的操作則可能會因為要更多來來回回而提高 latency

2. Two-Phase Commit
詳見: https://rickhw.github.io/2020/05/16/DistributedSystems/Distributed-Transactions/#Two-Phase-Commit-2PC
3. Saga
一種採用 Event-Bus 來交換訊息的非同步架構，可用來解決分散式架構下每個服務之間交易資料一制性問題的一種方式。
詳見 https://medium.com/程式愛好者/微服務-如何確定資料一致性-2adab03fdc7f

4. Replicated Load-Balanced Services
5. Sharded Services

其餘就詳見本文與其他網路資源

K8s log 消失於 Elasticsearch 的經驗談
https://povilasv.me/troubleshooting-missing-kubernetes-logs-in-elasticsearch/


EFK 是個非常常見的 log 處理組合，其架構下日誌的處理流程相對清楚，但是問題發生時並不好處理與除錯，以作者團隊來說，總是會發生掉 log 的情況，大概會有幾秒鐘的 log 都消失，因此本篇文章就是探討這問題的發生原因以及如何避免

文章大抵上分成三段
1. 探討常見 container runtime (Docker, Containerd, CRI-O) 是如何處理應用程式的 log
2. 探討 kubelet 是如何搭配上述 container runtime 去處理 log 的
3. 探討問題的原因本質， 到底 Fluentd 發生什麼問題

(1):
Docker 與 Containerd/CRI-O 處理 log 的方式截然不同， Docker 提供各式各樣的 logging driver 來處理大小與 rotation 的規定，而 CRI-O 這類型的本身沒有這些參數與處理，全部仰賴上層呼叫者，也就是 kubelet 去自行處理

(2):
Kubelet 底層會透過 symlink 的方式來設定一個當前 log 的檔案，該檔案則會指向目前最新的 log 內容，譬如
/var/log/containers/*.log -> /var/log/pods/$pod_id/$latest.log

symlink 本身不會注意到 rotate 的情況，這意味當一直關注 "/var/log/containers/*.log" 時，若目標檔案發生 log rotate 後，原先檔案的後半部分還沒有讀取到就會因為 log rotate 而沒有辦法順利讀取了

(3):
Fluentd 預設的 k8s log parser 之前會踩到上次的問題，一直關注 "/var/log/containers/*.log" 檔案，當 Pod 快速產生大量 log 內容並且觸發 log rotate 時， fluentd
還沒有讀取完全全部內容並且轉送出去，這時候檔案就被 rotate 因此就會發生掉 log 的內容

該 k8s log parser 後來有修正問題來處理，因此使用較新版本的 fluentd 就不會有這個問題

五個提升 Kubernetes 資安的小概念與步驟
https://blog.palark.com/kubernetes-security-best-practices/

根據 VMWare 以及 Dynatrace 於 2023 的使用者調查報告， Kubernetes 叢集的落地數量於雲端與私有地端都是逐年增加的趨勢，任何使用情境與規模都慢慢地轉往 Kubernetes 環境，同時根據 Red Hats 的 2023 Kubernetes Security 報告也顯示， 有 90% 的受訪者於過去一年內都有遇到 Security 的相關案例，且有 67% 的受訪者因為 Security 的關係目前正在趨緩全面導入 Kubernetes 的節奏

Kubernetes 本身是一個強大的平台，然而 Security 的導入並非一日工程，本身就是一個逐步提升與改善的流程，團隊開發者與應用程式開發人員需要互助慢慢協調找到一個彼此都舒適的節奏來調整所有流程，從 YAML 的撰寫到後期存取平台除錯等，每個環節其實與資安息息相關。

以 Security 來說，目前最知名的範本就是由非營利組織 CIS 所推行的 Kubernetes CIS Benchmark，也有相關的開源專案如 Kube-becnh, Kubeescape 等工具去實作 CIS Benchmark 來檢查你的 Cluster 並且提供相關報導。此外一個名為 PCI SSC(Payment Card Industry Security Standards Council) 的組織也發布了一個關於容器調度平台應該要注意的資安條件，該組織的組成來自 VISA, MasterCard 等金流相關的應用，因此資安方面也是極度重視。

文章內從五大點列出 Kubernetes 要著重的點，每個點都有很多細節探討，譬如
1. Proper Configuration of Kubernetes Clusters
2. Image Scanning
3. Networkg Security
4. Controlling Running Application
5. Auditing and Event Logging

簡述 Consistent Hashing 的概念與應用
https://www.toptal.com/big-data/consistent-hashing

Consistent Hashing 是一種基於分散式架構下的 Hash 演算法，主要應用於動態環境中，將 Hash 的請求或是資料給分散到不同節點(伺服器)上，但是當節點數量有任何增減時又要確保 Hash 的功能不會變影響。
舉例來說，假設本來系統有三台機器負責處理 Hash 後的結果，因此 Hash 演算法會使用 Mod 的概念將所有資料給分散於三台機器上

Value. Hash(Value). Mod 3
abc -> 13 -> 1
def -> 12 -> 0
geh -> 11 -> 2

假設今天因為流量等各種變化使得機器的數量變成 4 台，那這樣 Mod 的概念是否要改成 (Mod 4)? 若不改則新的機器就沒有辦法接收資料處理，若改成 Mod 4 則所有資料對應的機器都會改變
這樣會造成大量的 cache miss 最後影響整個系統效能。
Consistent Hashing 的目的是改善這個流程，當有任何節點更動時，目前既有的資料只有少部分會需要更動，其餘無關的都可以繼續保留本來的規則，而整體規劃都會牽扯到一個環，用環的概念來區分每筆資料應該由誰去處理，以及當節點數量增減之時該如何處置

三個 Kubernetes Nginx Ingress Controller 的 CVE
https://thehackernews.com/2023/10/urgent-new-security-flaws-discovered-in.html

Nginx Ingress Controller 最近有三個相關的 CVE 可以讓攻擊者有機會透過 Nginx Controller 來獲取叢集內其他的 secret 物件
這三個 CVE 一個是關於 Ingress 物件中 Path 的驗證問題，另外兩個則是跟 annotation 有關

目前的修復方式是將 NGINX 升級到 1.19 版本以後並且運行的時候加上 “–enable-annotation-validation” 的參數加入對 annotation 的驗證
若有要使用 NGINX 的情況則要注意下是否會踩到這些 CVE

Doordash 探討導入 Microservice 遇到的種種挑戰
https://blog.quastor.org/p/scaling-microservices-doordash

Microservice 出發點非常好，透過將元件分開並且獨立擴展讓整個系統可以更有效地去根據需求擴展，然而 Doordash 將服務轉移到 Microservice 的過程中則是遇到了各式各樣的問題
，而這些問題幾乎是所有 microserviec 架構下都會遇到的問題，包含

Cascading failures
Retry Storms
Death Spirals
Metasable Failures
這類型的錯誤幾乎都是因為現在服務之間的溝通從本來 Process 的溝通轉變為跨網路的服務呼叫，只要彼此之間因為網路或是各種原因出現短暫問題，就可能導致相關的服務依序出現錯誤
雖說透過 Retry 機制似乎可以解決，但是沒有妥善處理這些 Retry 的流量可能會使得系統更加惡化

因此其內部也透過 Circuit Braking, Load Shedding 以及 Auto-scaling 等機制來進行管理

最後也提到如何使用 https://github.com/fluxninja/aperture 這套開源專案來根據流量以及服務狀況來進行服務存取控制

Hashicorp Vault 因為授權問題而產生分歧
https://wiki.lfedge.org/display/OH/OpenBao+%28Hashicorp+Vault+Fork+effort%29+FAQ


Hashicorp 之前的授權更改於整個開源圈造成一股議論，最後社群直接 Fork Terraform 並且捐贈至 Linux Foundation 來進行社群運營，並且命名為 OpenTofu

如今 Hashicorp Vault 也發生一樣的命運，社群不滿授權機制，因此又 Fork Vault 並且一樣捐贈至 Linux Foundation 底下去進行發展，這次的名稱叫做 OpenBao

先撇開整個社群之間紛紛擾擾的貢獻議題，我更好奇的是
一下豆腐，一下包子...下一個是油條還是飯糰？

Kubernetres v1.28 non-graceful shutdown 探討
https://medium.com/@anavsaraf/kubernetes-planternetes-v1-28-non-graceful-node-shutdown-feature-8608d5073519

Kubernetes 於 1.24 推出， 1.26 轉往 Beta 的Non-GracefulNode Shutdown 功能 功能正式於 1.28 轉入穩定版本，該功能的目的是提供一種更好的機制去處理未預期節點狀況下的 Pod 生命週期。

該功能的誕生是希望能夠有效處理當 Kubernetes 節點不預期掛掉時發生的管理問題
以 StatefulSet 的應用程式來說，其本身因為講求狀態，所以必須要避免任何時間點有兩個重複的 Pod 出現，因此若需要更新其流程預設都是先砍掉舊的，然後重新部署新的。

但是對於非預期關機的節點(斷電，硬體壞掉等情境)來說，由於 Kubelet 沒有辦法正確回報狀況，所以這類型的 Pod 就會長時間處於 Terminating 的狀況，沒有辦法順利被回收，因此新的 Pod 就沒有辦法被創建起來。

此外 Volume 的部分也會因為 kubelet 卡住的關係，導致 Volume 沒有辦法順利的 detach，因此非預期的節點關機對於 stateful 的應用程式來說會有兩個痛點
1. Pod 卡在 Terminating ，新的 Pod 長不出來
2. Volume 卡住，無法順利 detach，新的 Pod 也用不了

於是 non-graceful shoutdown 的功能被引入 Kubernetes 希望能夠針對上述情境提供解法
目前的解法是需要人工介入，當節點發生問題時，只要快速地對該節點加上一個
node.kubernetes.io/out-of-service 的 Taint(NoSchedule or NoExecute)，內建的 Controller 就會立即的強制移除相關的 Pod 並且執行 Volume Detach 的動作來釋放相關資源，讓 stateful 的應用程式可以更快的於新節點重新部署來提供服務

如何於 Kubernetes 內動態掛上一個除錯專用容器
https://medium.com/datamindedbe/debugging-running-pods-on-kubernetes-2ba160c47ef5

Kubernetes 管理人員通常要對 Pod 進行除錯時，很常會使用 kubectl exec 等指令直接跳到 Pod 裡面去檢查當前的運行狀況。
kubectl exec 可以說是每個 Kubernetes 玩家都必定會且非常被大量使用的指令，但是該指令實際上會有一些限制

進去後的身份與指令實際上是仰賴於最初運行的容器狀態
由於上述的限制，所以到底有哪些指令可以運行非常仰賴當初打包 Image 使用的基底與指令，譬如使用 alpine 與 scratch 可以使用的指令與安裝方式就有非常大的不同，甚至有些環境連基本的 shell 都沒有，這種情況下除錯
此外現在愈來愈多的容器會以 non-root 的方式去執行，但是除錯的除錯的時候就是需要使用 root 來進行一些指令操作除錯，因此 kubect exec 這種直接繼承本來使用者身份的方式對於除錯來說稍嫌無力
為了解決這個問題， Kubernetes 官方提供了 kubectl debug 的指令，該指令可以動態的創建一個暫時 Container，並且將該 Container 掛載到任何選擇的 Pod 來進行除錯，該短暫 Container 可以共享既有的 Process namespace, network namespace 等，同時其所運行的 userID, groupID 則不受本來運行之限制，且該短暫 Container 的 Image 也可以自行選擇，所以就可以掛上自己常用的除錯 Container 來除錯。
該指令目前的缺陷就是預設的情況下無法共享 mount namespace，因此如果除錯的過成需要去觀看檔案系統的話，這方式會有點無力，因此文章提到可透過 patch 的方式動態的去修改 Pod spec，將 volumeMount 的資訊填上，該流程也被第三方包成一個 superdebug 的指令

此外還有其他工具如 kpexec 等都是想要強化既有 kubectl exec 的缺陷與限制

Container Runtime 抓取 Container Image 的過程介紹
https://itnext.io/exploring-oci-container-registries-by-use-case-pull-a-public-image-from-kubernetes-3d2d4267201c


過往使用 Container runtime (Docker, Containerd, CRI-O) 時，大家總是會學習到 Contianer Image 本身有快取的機制，能夠透過快取機制減少不必要的檔案抓取。此外 Kubernetes 內也有提供 ImagePullPolicy 等機制來設定抓取 Image 的策略。
本篇文章稍微探討了一下抓取 Image 中間的過程，包含

先從遠方 Repository 伺服器獲得該 Image 的一個小ID
確認本地有沒有該 ID 的 Image，有的話就代表本地擁有，不需要重複抓
若本地沒有，就代表需要抓取該 Image
接者就會去抓取該 Image 的第二層資料，該資料內會提供該 Image 用到的所有 layer 資訊
接下來每個 layer 獨自判別，若該 Layer 本地已經有快取，那就使用本地資料，否則從遠方抓取
從這個流程來看，本地沒有 Image 去遠方抓取並不代表是真的要去遠方抓取，若 Image Layer 本地已經有的情況下，部分 Layer 的抓取也是可以加速的，這意味如果以後要提高 Image 抓取的內容，除了探討 Image 本身的設定外，也許 Image Layer 的部分也值得研究看看，是否可以透過這些機制來降低每次抓取新版所需要的資料量與時間。

如何於 Bash 環境中產生有結構的 log
https://medium.com/picus-security-engineering/structured-logging-in-shell-scripting-dd657970cd5d

本篇文章作者探討如何使用 tail + bash redirection 等的方式來改善 bash script，讓檔案的輸出更有結構且能夠將個人的除錯 log 與指令的輸出有一個比較好的結構去分離，甚至可以加上不同的 log level，同時這些 log 可同時存放於檔案與 stdout 中。

為了讓 bash 運行過程的輸出可以同時寫到檔案與 stdout，作者於檔案內透過 tail 與 exec 的方式，後者會將該 script 內所有的 stdout/stderr 都導向特定檔案，同時透過 tail 的方式將檔案讀出給轉向 stdout 讓指令呼叫者也可以觀察到 log 的輸出。
有了基本機制後就是撰寫各種 wrapper function 來處理自己輸出的檔案格式。

如何透過幾種常見的 Image Cache 工具來加速 Kubernetes 內抓取 Image 的速度

https://medium.com/itnext/improve-container-image-availability-and-speed-with-caching-in-kubernetes-870fa7bfa1ed


Kubernetes 內應用程式從部署到真正運行中間所消耗的時間，有一段是仰賴於節點要花多少時間去抓取 Image，對於大小只有幾百甚至幾十MB 的應用程式來說
抓取 Image 的時間都非常的快，但是當有 Image 本身大小達到GB等級，同時節點上同時有多個 Pod 同時下載，這時候若超出平行下載限制時就會發生排隊等待的現象
最後就會導致部分應用程式花過長的時間才起來

這些流程對於更新應用程式來說也許不算什麼，畢竟既有的服務還在運作，但是對於節點掛掉或是 drain 的過程來說就會有比較大的影響，因為當下沒有服務正在運行，因此要如何更快速的
讓 Pod 被叫起來是一個值得關注的議題

本篇文章專注於如何加速 Image 下載的流程，介紹了下列幾個開源專案，每個專案都用不同的方式與架構來加速，包含
1. Kube-fledged
2. kube-image-keeper (kuik):
3. kubernetes-image-puller
4. Tugger

概念上大同小異，但是實作方式與目的都有些許不同

回顧 2023 年 Kubernetes 環境下的各種 Vulnerabilities

https://www.armosec.io/blog/kubernetes-vulnerabilities-2023/


根據統計，2019到2023 這幾年來看， Kubernetes 相關的 Vulnerabilities 數量幾乎翻了一倍，去年大概有 60 多條左右
這些 Vulnerabilities 大致上可以分成 Kubernetes 本身的問題以及相關生態系整合的問題，其中
1. Kubernetes 本身大概 11%
2. Cilium: 9%
3. ArgoCD 12%
4. Kyverno: 11%
5. KubePi: 6%
6. Others: 51%

作者從中整理了這些漏洞並且分類，可以分成下列幾項
1. Users can escalate into admin privileges by creating pods or persistent volumes on Windows nodes.
2. Users can launch containers and bypass the mountable secrets policy.
3. Users are able to bypass container image restrictions.
4. Pods can bypass the enforcement of the seccomp (secure computing mode) profile.
5. This entails improper privilege management in SUSE Rancher.
6. This entails improper authentication in Capsule Proxy, which leads to privilege escalation.

後兩者與特定工具有關，其餘前面四個類別也都有對應的 CVE 紀錄，總結來說隨者 Kubernetes 的應用愈來愈廣泛，資安的重視程度也要隨之提升，對團隊來說除了資安管控外，如何讓管理與開發不同的團隊能夠一起合作來提升資安風險也是另外一個重點，畢竟過多的限制有時候會對開發人員帶來過多的不便。