1——Kubernetes 1.13發布

2——Kubernetes首次出現重大安全漏洞

3——Docker和微軟公司推出雲原生應用的部署規範

4——谷歌推出beta版本的Cloud SCC

1 Kubernetes 1.13發布

Kubernetes在上周發布1.13版本，該版本繼續關註Kubernetes的穩定性和可擴展性。在這個版本中，用於簡化集群管理的kubeadm，容器存儲接口（CSI）實現GA，CoreDNS替代kube-dns成為默認DNS。

1.1 使用kubeadm簡化集群管理

大多數與Kubernetes親密接觸的人在某些時候都會親自動手使用kubeadm。它是管理集群生命周期的重要工具，從創建到配置再到升級; 現在kubeadm正式成為GA。kubeadm處理現有硬件上的生產集群的引導，並以最佳實踐方式配置Kubernetes核心組件，以便為新節點提供安全而簡單的連接流程並支持輕松升級。這個GA版本值得註意的是現在已經畢業的高級功能，特別是可插拔性和可配置性。kubeadm旨在成為管理員和自動化的高級別系統的工具箱，這個版本是朝這個方向邁出的重要一步。

1.2 容器存儲接口（CSI）

容器存儲接口（CSI）在v1.9中作為alpha版本引入，在v1.10成為beta，在v1.13實現GA。通過CSI，Kubernetes存儲變得真正可擴展。這為第三方存儲提供商提供了編寫與Kubernetes互操作而無需觸及核心代碼的插件的機會。這個規範本身也達到了1.0的狀態。

隨著CSI變得穩定，開發者可以按照自己的節奏,以out-of-tree的方式開發存儲插件。 您可以在CSI文檔中找到樣例和產品驅動程序的列表。

1.3 CoreDNS成為默認DNS

CoreDNS在v1.11中實現GA。在v1.13中，CoreDNS替換kube-dns成為Kubernetes的默認DNS服務器。CoreDNS是一個通用的、權威的DNS服務器，提供與Kubernetes向後兼容但可擴展的集成。CoreDNS比以前的DNS服務器具有更少的移動部件，因為它是單個可執行文件和單個進程，並通過創建自定義DNS條目來支持靈活的用例。它也用Go編寫，使其內存安全。

CoreDNS現在是Kubernetes 1.13+推薦的DNS解決方案。該項目已將常用測試基礎架構切換為默認使用CoreDNS，建議用戶進行切換。KubeDNS仍將至少支持到下一個版本，但現在是時候開始規劃遷移了。許多OSS安裝工具已經進行了切換，包括1.11中的Kubeadm。如果您使用托管解決方案，請與您的供應商合作，以了解這將如何影響您。

1.4 其他值得關註的功能更新

對第三方設備監控插件的支持已經作為alpha功能引入。這將從kubelet中刪除當前設備相關的知識，以使將來設備相關的用例變為out-of-tree。

Kubelet設備插件註冊逐漸穩定。這創建了一個通用的Kubelet插件發現模型，可以由不同類型的節點級插件（例如設備插件，CSI和CNI）用於與Kubelet建立通信通道。

拓撲感知卷調度現在是穩定的。這使調度器能夠識別Pod的卷的拓撲約束，例如zone或node。

APIServer DryRun升級為測試版。這將“應用”和聲明性對象管理從kubectl移動到apiserver，以便修復當前無法修復的許多現有bug。

Kubectl Diff升級為測試版。這允許用戶運行kubectl命令來查看本地聲明的對象配置與活動對象的當前狀態之間的差異。

使用持久卷的原始塊設備（Raw block device）升級為測試版。這使得原始塊設備（非網絡設備）可通過持久卷源進行消費。

2 Kubernetes 首次出現重大安全漏洞

Kubernetes出現了一個重大的的特權升級漏洞（CVE-2018-1002105）。***者通過構造特殊請求，可以在一個普通權限的鏈接上提升權限，向被代理的後端服務器發送任意請求。

該問題影響了幾乎Kubernetes目前所有的版本，包括：

Kubernetes v1.0.x-1.9.x

Kubernetes v1.10.0-1.10.10 (fixed in v1.10.11)

Kubernetes v1.11.0-1.11.4 (fixed in v1.11.5)

Kubernetes v1.12.0-1.12.2 (fixed in v1.12.3)

2.1 什麽樣的集群可能被***？

集群啟用了擴展API server，並且kube-apiserver與擴展API server的網絡直接連通；

集群對***者可見，即***者可以訪問到kube-apiserver的接口，如果你的集群是部署在安全的私網內，那麽不會有影響；

集群開放了 pod exec/attach/portforward 接口，則***者可以利用該漏洞獲得所有的kubelet API訪問權限。

2.2 具體影響的場景

集群使用了聚合API，只要kube-apiserver與聚合API server的網絡直接連通，***者就可以利用這個漏洞向聚合API服務器發送任何API請求；

如果集群開啟了匿名用戶訪問的權限，則匿名用戶也利用這個漏洞。不幸的是K8s默認允許匿名訪問，即kube-apiserver的啟動參數”-- anonymous-auth=true”；

給予用戶Pod的exec/attach/portforward的權限，用戶也可以利用這個漏洞升級為集群管理員，可以對任意Pod做破壞操作；

Kubernetes已發布更新以解決該漏洞（v1.10.11，v1.11.5和v1.12.3）。

更多信息見社區Issue：

https://github.com/kubernetes/kubernetes/issues/71411

3 Docker和微軟推出雲原生應用部署規範

根據微軟的新聞稿，微軟和Docker聯合宣布了一個新項目，旨在創建“一個用於打包和運行分布式應用程序的開源，雲無關的規範”。

該項目的名稱為雲原生應用程序包（Cloud Native Application Bundle，CNAB），為開發人員提供了一種標準方法，可以在許多計算環境中打包和運行容器化應用程序，從工作站上的Docker到雲實例中的Kubernetes。

CNAB的規範描述了構成應用程序的“包”或資源組。應用程序包還描述了如何安裝，升級或刪除應用程序，以及如何在不同環境之間移動應用程序，即使目標環境不在線（例如氣隙系統）。微軟宣稱，即使底層技術本身不支持，也可以對應用程序包進行數字簽名和驗證。應用程序包可以部署在組織內部，也可以通過現有的分發系統（比如Docker Hub和DockerTrustRegistry）進行部署。

在容器環境中創建應用程序包的技術已經存在，例如Kubernetes的Helm，它描述了如何組合多個容器來定義應用程序堆棧。 CNAB針對的是更為全面的用例集，它不僅適用於Kubernetes，還適用於部署和管理容器的其他系統。

CNAB的另一個既定目標是減少創建應用程序定義所需的工具數量。 CNAB定義可以自動生成特定於部署目標的定義文件（例如，Helm圖表或Compose模板），以便用戶無需掌握多個工具集即可部署到多個目標。

Docker和微軟都計劃發布CNAB的開發工具。微軟宣布將提供Visual Studio代碼擴展，以便更容易創建CNAB包，以及實現CNAB規範的開源示例（“Duffle”）。 Docker打算將CNAB支持添加到Docker App工具的新版本中，以便可以在Docker Enterprise的實例中維護CNAB定義的應用程序。

4 谷歌推出beta版本的Cloud SCC

谷歌近日推出了一項新的測試版本的安全服務，作為信息技術團隊的集中門戶，統一安全漏洞數據，並在任何損害發生之前對潛在威脅采取行動。

該公司表示，Cloud SCC(Cloud Security Command Center)的測試版的發布使其成為第一家為漏洞和威脅提供“組織級可見性”的公有雲提供商。

Cloud SCC於3月份啟動alpha版本。當時，谷歌將其描述為雲的“安全和風險平臺”，通過收集數據和識別潛在威脅，防止它們造成任何損害。通過整合對App Engine，計算引擎，雲存儲和雲數據存儲等服務的可視性，它可以幫助管理員了解這些環境中的任何更改並減少未經授權的更改。

Cloud SCC的beta版涵蓋了其他服務，包括雲數據存儲，雲DNS，雲負載平衡，雲量計，容器註冊，Kubernetes引擎和虛擬私有雲。它還增加了新功能，包括13個新的身份訪問管理角色，可用於控制對Google雲資源的訪問。

“借助Cloud SCC，您可以查看和監控雲資產清單，發出安全異常警報，掃描雲存儲以發現存儲敏感數據的位置，檢測常見Web漏洞以及查看關鍵資源的訪問權限，所有都通過一個集中的數據平臺和儀表盤，Google產品經理Andy Chang在博客文章中寫道。

Chang接著解釋了可以使用Cloud SCC改善公司安全狀況的三種方式。第一種方法是通過識別可公開訪問的雲存儲桶或具有可能暴露給未授權人員的公共地址的虛擬機來發現潛在的安全風險。

Cloud SSC還允許管理員查看和處理對谷歌雲平臺資產所做的更改。 該服務執行持續的發現掃描，允許用戶查看其資產歷史記錄，以準確了解其環境中發生的變化，並對未經授權的修改采取行動。

Chang表示，Cloud SSC可以與其他安全服務集成，其中包括Google的Data Loss Prevention API，Forseti和Cloud Security Scanner工具，以及來自Cavirin Systems，Cloudflare和Redlock等公司的第三方安全產品。

“通過將合作夥伴解決方案與Cloud SSC集成，您可以在一個地方全面了解風險和威脅，而無需單獨使用控制臺，”Chang說。

Cloud Native Weekly | Kubernetes 1.13發布