K8s近期漏洞詳解
Kubernetes儀表盤漏洞（CVE-2018-18264）
因爲這一漏洞，用戶可以“跳過”登錄過程獲得儀表盤所使用的自定義TLS證書。如果您已將Kubernetes儀表盤配置爲需要登錄並將其配置爲使用自定義TLS證書，那麼這一漏洞會影響到您。
具體來說，該漏洞的運作原理是：
首先，因爲登陸時用戶可以選擇“跳過”這一選項，那麼任何用戶都可以繞過登錄過程，該過程在v1.10.0或更早版本中始終默認啓用。這樣一來，用戶就完全跳過登錄過程並能使用儀表盤配置的服務賬戶。
之後，使用儀表盤配置的服務賬戶，必須最低限度地有權限訪問自定義TLS證書（以secret的形式存儲）。未經身份驗證的登錄，加上儀表板使用配置的服務賬戶來檢索這些secret的能力，組合在一起的結果就是這一安全問題。
社區已經在儀表盤v1.10.1對這個漏洞進行了修復，默認情況下將不再啓用“跳過”選項，並且會禁用儀表盤在UI中檢索和顯示它的功能。
參考鏈接：
issue:
https://github.com/kubernetes/dashboard/issues/2668
修復pr:
https://github.com/kubernetes/dashboard/pull/3289
漏洞描述:
https://nvd.nist.gov/vuln/detail/CVE-2018-18264
Kubernetes API服務器外部IP地址代理漏洞
Kubernetes API server可以使用pod、node或service代理api，將請求代理的pod或節點上，通過修改podIP或nodeIP，可以將代理請求定向到任何IP。API server總是被部署在某網絡中的，利用這個漏洞就訪問該網絡中的任何可用IP了。
該漏洞的具體運作原理是：
通過使用Kubernetes API，用戶可以使用節點代理、pod代理或服務代理API請求與pod或節點的連接。Kubernetes接受此請求，找到podIP或nodeIP的關聯IP，並最終將該請求轉發到該IP。這些IP通常由Kubernetes自動分配。但是，集羣管理員（或具有類似“超級用戶”權限的不同角色）可以更新資源的podIP或nodeIP字段以指向任意IP。
這在很大程度上不是問題，因爲“普通”用戶無法更改資源的podIP或nodeIP。podIP和nodeIP字段位於pod和節點資源的狀態子資源中。爲了更新狀態子資源，必須專門授予RBAC規則。默認情況下，除了集羣管理員和內部Kubernetes組件（例如kubelet、controller-manager、scheduler）之外，沒有Kubernetes角色可以訪問狀態子資源。想要利用此漏洞，首先得擁有對集羣的高級別訪問權限。
但是在一些特殊場景下，比如雲提供商爲用戶提供的kubernetes集羣，API server可能和集羣運行在不同的平面，集羣管理員不能訪問運行API server的主機。
參考鏈接：
修復pr:
https://github.com/kubernetes/kubernetes/pull/71980
社區討論:
Kubernetes-csi 日誌漏洞
Kubernetes-csi（container storage interface）是kubernetes提供的一種容器存儲接口，kubernetes可以與街上上運行的外部csi卷驅動程序交互，從而可以將任意存儲系統暴露給自己的容器工作負載。
根據我們介紹的這個漏洞，借點上運行的kubernetes-csi sidecars，當日志級別提高到5或者更高時，會打印所有CSI RPC請求和響應的信息，其中包括請求過程中使用的secret的詳細信息。這顯然是不能接受的。
目前該漏洞的修復僅涉及kubernetes-csi項目維護的組件，包括：
kubernetes-csi/external-attacher: v0.4.1 and older, v1.0.0 and older
kubernetes-csi/external-provisioner: v0.4.1 and older, v1.0.0 and older
kubernetes-csi/drivers (iscsi-only): v0.4.1 and older, v1.0.1 and older
如果您正在使用上述版本，可以將組件升級到下面版本以解決這個漏洞：
kubernetes-csi/external-attacher: v0.4.2, v1.0.1
kubernetes-csi/external-provisioner: v0.4.2, v1.0.1
kubernetes-csi/drivers (iscsi-only): v0.4.2, v1.0.1
而其他csi driver提供商也應該評估是否存在相似的問題。
12/25-1/22 1.13bug fix彙總
12/25-1/22期間，雖然沒有特別嚴重的bug，但是需要關注的漏洞修復比較多，且都涉及到比較核心的組件和功能。
1.11.3重要bug fix解讀
