點擊下載《不一樣的 雙11 技術(shù)：阿里巴巴經(jīng)濟體云原生實踐》

創(chuàng)新互聯(lián)專注于奇臺企業(yè)網(wǎng)站建設(shè),成都響應式網(wǎng)站建設(shè),商城開發(fā)。奇臺網(wǎng)站建設(shè)公司,為奇臺等地區(qū)提供建站服務。全流程定制開發(fā)，專業(yè)設(shè)計，全程項目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務

本文節(jié)選自《不一樣的 雙11 技術(shù)：阿里巴巴經(jīng)濟體云原生實踐》一書，點擊上方圖片即可下載！

作者
楊寧（麟童） 阿里云基礎(chǔ)產(chǎn)品事業(yè)部高級安全專家
劉梓溪（寞白） 螞蟻金服大安全基礎(chǔ)安全安全專家
李婷婷（鴻杉） 螞蟻金服大安全基礎(chǔ)安全資深安全專家

簡介

零信任安全最早由著名研究機構(gòu) Forrester 的首席分析師約翰.金德維格在 2010 年提出。零信任安全針對傳統(tǒng)邊界安全架構(gòu)思想進行了重新評估和審視，并對安全架構(gòu)思路給出了新的建議。

其核心思想是，默認情況下不應該信任網(wǎng)絡(luò)內(nèi)部和外部的任何人/設(shè)備/系統(tǒng)，需要基于認證和授權(quán)重構(gòu)訪問控制的信任基礎(chǔ)。諸如 IP 地址、主機、地理位置、所處網(wǎng)絡(luò)等均不能作為可信的憑證。零信任對訪問控制進行了范式上的顛覆，引導安全體系架構(gòu)從“網(wǎng)絡(luò)中心化”走向“身份中心化”，其本質(zhì)訴求是以身份為中心進行訪問控制。

目前落地零信任概念包括 Google BeyondCorp、Google ALTS、Azure Zero Trust Framework 等，云上零信任體系，目前還是一個新興的技術(shù)趨勢方向，同樣的零信任模型也同樣適用于 Kubernetes，本文重點講解一下 Kubernetes 下零信任安全架構(gòu)的技術(shù)分析。

傳統(tǒng)零信任概念和目前落地情況

Microsoft Azure

Azure 的零信任相對來說還是比較完善的，從體系角度來看涵蓋了端、云、On-Permises、SaaS 等應用，下面我們分析一下相關(guān)的組件：

• 用戶 Identity：然后通過 Identity Provider（創(chuàng)建、維護和管理用戶身份的組件）的認證，再認證的過程中可以使用賬號密碼，也可以使用 MFA（Multi Factor Auth）多因素認證的方式，多因素認證包括軟、硬 Token、SMS、人體特征等；
• 設(shè)備 Identity：設(shè)備包含了公司的設(shè)備以及沒有統(tǒng)一管理的設(shè)備，這些設(shè)備的信息，包含 IP 地址、MAC 地址、安裝的軟件、操作系統(tǒng)版本、補丁狀態(tài)等存儲到 Device Inventory；另外設(shè)備也會有相應的 Identity 來證明設(shè)備的身份；設(shè)備會有對應的設(shè)備狀態(tài)、設(shè)備的風險進行判定；
• Security Policy Enforcement：通過收集的用戶 Identity 以及狀態(tài)、設(shè)備的信息，狀態(tài)以及 Identity 后，SPE 策略進行綜合的判定，同時可以結(jié)合 Threat Intelligence 來增強 SPE 的策略判定的范圍和準備性；策略的例子包括可以訪問后面的 Data、Apps、Infrastructure、Network；
• Data：針對數(shù)據(jù)（Emails、Documents）進行分類、標簽、加密的策略；
• Apps：可以自適應訪問對應的 SaaS 應用和 On-Permises 應用；
• Infrastructure：包括 IaaS、PaaS、Container、Serverless 以及 JIT（按需開啟訪問）和 GIT 版本控制軟件；
• Network：針對網(wǎng)絡(luò)交付過程以及內(nèi)部的微隔離進行策略打通。

下面這張微軟的圖進行了更加細化的講解，用戶（員工、合作伙伴、用戶等）包括 Azure AD、ADFS、MSA、Google ID 等，設(shè)備（可信的合規(guī)設(shè)備）包括 Android、iOS、MacOS、Windows、Windows Defender ATP，客戶端（客戶端 APP 以及認證方式）包括瀏覽器以及客戶端應用，位置（物理和虛擬地址）包括地址位置信息、公司網(wǎng)絡(luò)等，利用 Microsoft 的機器學習 ML、實時評估引擎、策略等進行針對用戶、客戶端、位置和設(shè)備進行綜合判定，來持續(xù)自適應的訪問 On-Permises、Cloud SaaS Apps、Microsoft Cloud，包含的策略包括 Allow、Deny，限制訪問、開啟 MFA、強制密碼重置、阻止和鎖定非法認證等；從下圖可以看出 Azure 已經(jīng)打通了 On-Permises、Cloud、SaaS 等各個層面，構(gòu)建了一個大而全的零信任體系。

Google BeyondCorp

Google BeyondCorp 是為了應對新型網(wǎng)絡(luò)威脅的一種網(wǎng)絡(luò)安全解決方案，其實 Google BeyondCorp 本身并沒有太多的技術(shù)上的更新?lián)Q代，而是利用了持續(xù)驗證的一種思路來做的，去掉了 *** 和不再分內(nèi)外網(wǎng)。Google 在 2014 年之前就預測到互聯(lián)網(wǎng)和內(nèi)網(wǎng)的安全性是一樣危險的，因為一旦內(nèi)網(wǎng)邊界被突破的話，***者就很容易的訪問企業(yè)的一些內(nèi)部應用，由于安全意識的問題導致企業(yè)會認為我的內(nèi)部很安全，我就對內(nèi)部的應用進行低優(yōu)先級別的處理，導致大量內(nèi)部的安全問題存在。現(xiàn)在的企業(yè)越來越多的應用移動和云技術(shù)，導致邊界保護越來越難。所以 Google 干脆一視同仁，不分內(nèi)外部，用一樣的安全手段去防御。

從***角度來看一下 Google 的 BeyondCorp 模型，例如訪問 Google 內(nèi)部應用http://blackberry.corp.google.com ，它會跳轉(zhuǎn)到https://login.corp.google.com/ 也就是 Google Moma 系統(tǒng)，首先需要輸入賬號密碼才能登陸，這個登錄的過程中會針對設(shè)備信息、用戶信息進行綜合判定，賬號密碼正確以及設(shè)備信息通過規(guī)則引擎驗證之后，會繼續(xù)跳轉(zhuǎn)到需要 YubiKey 登錄界面，每個 Google 的員工都會有 Yubikey，通過 Yubikey 來做二次驗證。Yubikey 的價值，Google 認為是可以完全杜絕釣魚***的。另外類似的就是 Amazon 的 Midway-Auth 方式?（ https://midway-auth.amazon.com/login?next=%2F?）。

Kubernetes 下容器零信任模型

容器下網(wǎng)絡(luò)零信任

首先介紹一下容器下的網(wǎng)絡(luò)零信任組件 Calico，Calico 是針對容器，虛擬機和基于主機的本機 Workload 的開源網(wǎng)絡(luò)和網(wǎng)絡(luò)安全解決方案產(chǎn)品。Calico 支持廣泛的平臺，包括 Kubernetes、OpenShift、Docker EE、OpenStack 和裸金屬服務。零信任大的價值就是即使***者通過其他各種手法破壞應用程序或基礎(chǔ)架構(gòu)，零信任網(wǎng)絡(luò)也具有彈性。零信任架構(gòu)使得使***者難以橫向移動，針對性的踩點活動也更容易發(fā)現(xiàn)。

在容器網(wǎng)絡(luò)零信任體系下，Calico+Istio 目前是比較熱的一套解決方案；先來看看兩者的一些差別，從差別上可以看到 Istio 是針對 Pod 層 Workload 的訪問控制，以及 Calico 針對 Node 層的訪問控制：

	Istio	Calico
Layer	L3-L7	L3-L4
實現(xiàn)方式	用戶態(tài)	內(nèi)核態(tài)
策略執(zhí)行點	Pod	Node

下面重點講解一下 Calico 組件和 Istio 的一些技術(shù)細節(jié)，Calico 構(gòu)建了一個 3 層可路由網(wǎng)絡(luò)，通過 Calico 的 Felix（是運行在 Node 的守護程序，它在每個 Node 資源上運行。Felix 負責編制路由和 ACL 規(guī)則以及在該 Node 主機上所需的任何其他內(nèi)容，以便為該主機上的資源正常運行提供所需的網(wǎng)絡(luò)連接）運行在每個 Node 上，主要做路由和 ACL 的策略以及搭建網(wǎng)絡(luò)；通過運行在 Node 上的 Iptables 進行細粒度的訪問控制?？梢酝ㄟ^ Calico 設(shè)置默認 Deny 的策略，然后通過自適應的訪問控制來進行最小化的訪問控制策略的執(zhí)行，從而構(gòu)建容器下的零信任體系；Dikastes/Envoy：可選的 Kubernetes sidecars，可以通過相互 TLS 身份驗證保護 Workload 到 Workload 的通信，并增加相關(guān)的控制策略；

Istio

再講解 Istio 之前先講一下微服務的一些安全需求和風險分析：

1、微服務被突破之后通過 Sniffer 監(jiān)控流量，進而進行中間人***，為了解決這種風險需要對流量進行加密；
2、為了針對微服務和微服務之間的訪問控制，需要雙向 TLS 和細粒度的訪問策略；
3、要審核誰在什么時候做了什么，需要審計工具；

分析了對應的風險之后，下面來解釋一下 Istio 如何實現(xiàn)的零信任架構(gòu)。首先很明顯的一個特點就是全鏈路都是雙向 mTLS 進行加密的，第二個特點就是微服務和微服務之間的訪問也可以進行鑒權(quán)，通過權(quán)限訪問之后還需要進行審計。Istio 是數(shù)據(jù)面和控制面進行分離的，控制面是通過 Pilot 將授權(quán)策略和安全命名信息分發(fā)給 Envoy，然后數(shù)據(jù)面通過 Envoy 來進行微服務的通信。在每個微服務的 Workload 上都會部署 Envoy，每個 Envoy 代理都運行一個授權(quán)引擎，該引擎在運行時授權(quán)請求。當請求到達代理時，授權(quán)引擎根據(jù)當前授權(quán)策略評估請求上下文，并返回授權(quán)結(jié)果 ALLOW 或 DENY。

微服務下的 Zero Trust API 安全

42Crunch（ https://42crunch.com/ ）將 API 安全從企業(yè)邊緣擴展到了每個單獨的微服務，并通過可大規(guī)模部署的超低延遲微 API 防火墻來進行保護。 42Crunch API 防火墻的部署模式是以 Kubernetes Pod 中以 Sidecar 代理模式部署，毫秒級別的性能響應。 這省去了編寫和維護單個 API 安全策略過程，并實施了零信任安全體系結(jié)構(gòu)，提升了微服務下的 API 安全性。42Crunch 的 API 安全能力包括：審核：運行 200 多個 OpenAPI 規(guī)范定義的安全審核測試，并進行詳細的安全評分，以幫助開發(fā)人員定義和加強 API 安全；掃描：掃描實時 API 端點，以發(fā)現(xiàn)潛在的漏洞；保護：保護 API 并在應用上部署輕量級，低延遲 Micro API Firewall。

螞蟻零信任架構(gòu)體系落地最佳實踐

隨著 Service Mesh 架構(gòu)的演進，螞蟻已經(jīng)開始在內(nèi)部落地 Workload 場景下的服務鑒權(quán)能力，如何建設(shè)一套符合螞蟻架構(gòu)的 Workload 間的服務鑒權(quán)能力，我們將問題分為一下三個子問題：

1、Workload 的身份如何定義，如何能夠?qū)崿F(xiàn)一套通用的身份標識的體系；
2、Workload 間訪問的授權(quán)模型的實現(xiàn)；
3、訪問控制執(zhí)行點如何選擇。

Workload 身份定義 & 認證方式

螞蟻內(nèi)部使用 SPIFFE 項目中給出的 Identity 格式來描述 Workload 的身份，即：

spiffe://<domain>/cluster/<cluster>/ns/<namespace>

不過在工程落地過程中發(fā)現(xiàn)，這種維度的身份格式粒度不夠細，并且與 K8s 對于 namespace 的劃分規(guī)則有較強的耦合。螞蟻的體量較大，場景較多，不同場景下 namespace 的劃分規(guī)則都不完全一致。因此我們對格式進行了調(diào)整，在每一場景下梳理出能夠標識一個 Workload 示例所須要的一組必備屬性（例如應用名，環(huán)境信息等），并將這些屬性攜帶在 Pod 的 Labels 中。調(diào)整后的格式如下：

spiffe://<domain>/cluster/<cluster>/<required_attr_1_name>/<required_attr_1_value>/<required_attr_2_name>/<required_attr_2_value>

配合這個身份格式標準，我們在 K8s API Server 中添加了 Validating Webhook 組件，對上述 Labels 中必須攜帶的屬性信息進行校驗。如果缺少其中一項屬性信息，則實例 Pod 將無法創(chuàng)建。如下圖所示：

在解決了 Workload 身份定義的問題后，剩下的就是如何將身份轉(zhuǎn)換成某種可校驗的格式，在 Workload 之間的服務調(diào)用鏈路中透傳。為了支持不同的使用場景，我們選擇了 X.509 證書與 JWT 這兩種格式。

對于 Service Mesh 架構(gòu)的場景，我們將身份信息存放在 X.509 證書的 Subject 字段中，以此來攜帶 Workload 的身份信息。如下圖所示：

對于其他場景，我們將身份信息存放在 JWT 的 Claims 中，而 JWT 的頒發(fā)與校驗，采用了 Secure Sidecar 提供服務。如下圖所示：

授權(quán)模型

在項目落地的初期，使用 RBAC 模型來描述 Workload 間服務調(diào)用的授權(quán)策略。舉例描述，應用 A 的某一個服務，只能被應用 B 調(diào)用。這種授權(quán)策略在大多數(shù)場景下都沒有問題，不過在項目推進過程中，我們發(fā)現(xiàn)這種授權(quán)策略不適用于部分特殊場景。<br />我們考慮這樣一個場景，生產(chǎn)網(wǎng)內(nèi)部有一個應用 A，職責是對生產(chǎn)網(wǎng)內(nèi)部的所有應用在運行時所需要使用的一些動態(tài)配置提供中心化的服務。這個服務的定義如下：A 應用 - 獲取動態(tài)配置的 RPC 服務：

message FetchResourceRequest {
// The appname of invoker
string appname = 1;
// The ID of resource
string resource_id = 2;
}
message FetchResourceResponse {
string data = 1;
}
service DynamicResourceService {
rpc FetchResource (FetchResourceRequest) returns (FetchResourceResponse) {}
}

在此場景下，如果依然使用 RBAC 模型，應用 A 的訪問控制策略將無法描述，因為所有應用都需要訪問 A 應用的服務。但是這樣會導致顯而易見的安全問題，調(diào)用方應用 B 可以通過該服務獲取到其它應用的資源。因此我們將 RBAC 模型升級為 ABAC 模型來解決上述問題。 我們采用 DSL 語言來描述 ABAC 的邏輯，并且集成在 Secure Sidecar 中。

訪問控制執(zhí)行點的選擇

在執(zhí)行點選擇方面，考慮到 Service Mesh 架構(gòu)推進需要一定的時間，我們提供了兩不同的方式，可以兼容 Service Mesh 的架構(gòu)，也可以兼容當前場景。

在 Service Mesh 架構(gòu)場景下，RBAC Filter 和 ABAC Filter（Access Control Filter）集成在 Mesh Sidecar 中。

在當前場景下，我們目前提供了 JAVA SDK，應用需要集成 SDK 來完成所有認證和授權(quán)相關(guān)的邏輯。與 Service Mesh 架構(gòu)場景類似，所有 Identity 的頒發(fā)、校驗，授權(quán)與 Secure Sidecar 交互，由 Secure Sidecar 完成。

結(jié)語

零信任的核心是“Never Trust， Always Verify”，未來會繼續(xù)深化零信任在整個阿里巴巴的實踐，賦予不同的角色不同的身份，例如企業(yè)員工、應用、機器，并將訪問控制點下沉到云原生基礎(chǔ)設(shè)施的各個點，實現(xiàn)全局細粒度的控制，打造安全防護的新邊界。本文從業(yè)界的零信任體系的落地最佳實踐，到基于 Kubernetes 的零信任落地方式進行了簡單的描述，本文只是拋磚引玉，希望能引發(fā)更多關(guān)于 Cloud Native 下的零信任架構(gòu)體系的更多討論和能看到更多的業(yè)界優(yōu)秀的方案和產(chǎn)品能出現(xiàn)。

本書亮點

• 雙11 超大規(guī)模 K8s 集群實踐中，遇到的問題及解決方法詳述
• 云原生化最佳組合：Kubernetes+容器+神龍，實現(xiàn)核心系統(tǒng) 100% 上云的技術(shù)細節(jié)
• 雙 11 Service Mesh 超大規(guī)模落地解決方案

“阿里巴巴云原生關(guān)注微服務、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的技術(shù)圈。”

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

當前題目：Kubernetes下零信任安全架構(gòu)分析-創(chuàng)新互聯(lián)
瀏覽地址：http://aaarwkj.com/article28/jsocp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供移動網(wǎng)站建設(shè)、品牌網(wǎng)站建設(shè)、服務器托管、做網(wǎng)站、小程序開發(fā)、自適應網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)