雲原生一週精選
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說。