雲原生時代的 Identity

作者：

艾競，花名庭堅，螞蟻金服系統部研究員

李婷婷，花名鴻杉，螞蟻金服平台安全資深安全專家

背景

随着輕量級容器（container）的興起，應用（applications）逐漸由單體（monolithic）向微服務（micro-service）演進。相應的，應用的微服務化也帶來了如下的變化：

• 軟體研發、運維人員組織圍繞着微服務下的軟體子產品重新架構：研發、運維人員分化成更小的組織以專注于一個或多個軟體子產品（以容器的形式傳遞）；在微服務 API 穩定的情況下，各個子產品獨立開發，測試和部署可以進行更高速的疊代
• 應用中軟體子產品之間由函數調用的“強”耦合變成網絡遠端調用的“松”耦合；維持原先各個子產品之間的信任需要有額外的安全機制

另一方面，除了桌上型電腦（desktop），其它可以接入應用的實體裝置（device），例如筆記本電腦（laptop），手機（mobile phone），也已經大規模普及。是以，企業員工通常擁有多個裝置來通路企業應用以完成日常工作。個人多裝置以及裝置的移動性對于企業傳統的安全邊界模型（perimeter model）提出了挑戰。

可以觀察到，在應用由單體向微服務，裝置由單一、靜态向多種、移動的演化下，系統中各個 Entity（實體，例如，人，裝置，服務等）的 Identity（身份），由單一的網絡辨別，即 IP 或者 IP：Port，向多種形态（X.509 certificate, token, service account 等）分化。Identity 的分化會對研發、運維效能和資源效能也會産生深刻的影響。

在這些背景下，傳統基于 IP、域名的管控方式臨着巨大的挑戰，靜态的規則讓安全政策變得無法維護；同時，在微服務架構下，安全人員很難快速找到一條邊界，将不同的風險域隔離開來。是以，急需一種新 Access Control 模式來應對。

Forrester 的首席分析師約翰·金德維格在 2010 年提出了零信任（Zero Trust）的理念針對傳統邊界安全架構思想進行了重新評估和審視，并對安全架構思路給出了新的建議，其核心思想是 "Never Trust，Always Verify" - All network traffic is untrusted. There is no "trusted traffic"。阿裡巴巴已經在内部開始推進零信任架構的落地，包括企業内部接入層的零信任、生産網内部機器、應用間的零信任，并已經開始在 雙11 中發揮了重要的作用。

零信任第一個核心問題就是 Identity，賦予不同的 Entity 不同的 Identity，解決是誰在什麼環境下通路某個具體的資源的問題。是以，本文将從 Identity 與微服務和 Identity 與企業應用通路兩個方面來闡述 Identity 在生産應用和企業應用中的思考，同時也會介紹在不同的場景下如何利用 Identity 解決誰在什麼環境可以通路某個資源的具體實踐。

Identity 與微服務

随着使用者需求在資訊化時代的日益增長，軟體也變得越來越複雜。為了應對軟體複雜度的提升，軟體的架構也由簡單的單體應用逐漸演變成為複雜的微服務應用。2017 年，Kubernetes 開始成為事實上的标準容器編排平台。同一年，谷歌聯合 IBM，Lyft 推出的 Istio 主打 SideCar 模式下的微服務治理。至此，在雲原生時代，應用得以在 Kubernetes 和 Istio 構成的底座之上以容器的形式微服務化。

在雲原生的轉型中，軟體研發、運維組織架構需要圍繞微服務來重新建構：如果把一組在邏輯、功能上耦合緊密的軟體子產品看作一門“功夫”的話，它們背後的研發、運維人員就是一個“武林門派”；各個“武林門派”相對獨立的“修煉”自己的“功夫”；配合起來，又能滿足軟體系統整體的演進。然而，這套适配微服務的組織架構對于研發、運維模式提出了很大的挑戰。歸結到一點：就是從每個研發、運維者的角度，如何在關注本門“功夫”的同時保證軟體系統整體的可用性。

Identity 由單一網絡位址變得更多元化以辨別不同的對象（例如，使用者，使用者組，服務等）為應對上述挑戰提供了可能性。接下來，我們會看到 Identity 是如何覆寫整個軟體開發周期各個場景為每個研發、運維者創造相對隔離的“環境”的。

Identity 與 Kubernetes 叢集

首先，我們來看 Identity 是如何依據使用者/使用者組提供所需 Kubernetes 叢集資源的。Kubernetes 叢集是用于容器生命周期管理的。細分一下，其使用者大緻可以分為如下兩類：

• Kubernetes 叢集的管理者：關注叢集本身，主要的職責包括并不限于：
  • Kuberentes 元件的維護及更新
  • Kuberentes 叢集中 Node 的治理
  • Kuberentes 叢集中 Namespace 的治理
  • Kuberentes 叢集中各類 policy（例如，Role-Based Access Control（RBAC） for AuthZ）的治理
  • Kuberentes 叢集中 Pod 排程管理
  • Kuberentes 叢集中 C[X]I（例如，CRI，CNI，CSI 等）的治理
  • Kuberentes 叢集資源容量管理
  • 。。。
• Kubernetes 叢集的使用者：關注如何在叢集之上運作容器，依據角色（例如，開發/測試/運維）的不同，主要的使用方式有：
  • Kuberentes 叢集中 Service Account 的治理
  • 将 Kubernetes 叢集作為開發環境
  • 将 Kubernetes 叢集作為線下測試環境，運作 CI/CD
  • 将 Kubernetes 叢集作為線上釋出環境，進行灰階，復原等操作

對于第一類 Kubernetes 叢集使用者，可以通過 Kubernetes RBAC 機制下 ClusterRoleBinding 賦予叢集級别權限；并且需要“壟斷”叢集和 Namespace 級别政策的制定；為了防止敏感資訊洩露，還需要将叢集和 Namespace 級别的資訊以及敏感資訊（例如 Secret）設定為僅為 Kubernetes 叢集管理者可見。

對于第二類 Kubernetes 叢集使用者，可以進一步按照對應的微服務中軟體子產品來進行細分成不同的組（Group）。另一方面，Kubernetes Namespace 提供了虛拟叢集的抽象。是以，當 Kubernetes API Server 認證使用者身份之後，可以按照組的粒度将使用者映射到 Kubernetes 叢集某個 Namespace 的角色（Role）而這個角色在此 Namespace 中擁有相應權限。具體來說，使用者到 Namespace 的映射可以通過 Kubernetes RBAC 機制下 RoleBinding 完成。考慮到系統政策的可維護性，以組 Identity 的粒度制定政策而以使用者 Identity 用于審計（Audit）是合理的。

Kubernetes 中并沒有代表使用者的資源，并且企業一般都會擁有多個 Kubernetes 叢集。是以，提供組織架構資訊（例如，使用者（User），組（Group））的 Identity Provider（IdP）應該獨立于 Kubernetes 叢集之外并可以服務多個 Kubernetes 叢集。如果對多個 Kubernetes 叢集采用相同的配置，使用者可以收獲跨叢集的一緻性使用者體驗。

圖 1：Identity Provider 與 Kubernetes 叢集

在 IdP 中的組織架構，一個組可以包含使用者，也可以包含其他組；與此同時，一個使用者也可以直接棣屬于多個組。是以可以根據使用者操作（使用者執行的 yaml 檔案中指定了具體的 Namespace）來更加靈活映射到不同的角色來操作相應的 Kubernetes Namespace：

• 例子一：一個使用者按架構域劃分屬于 A 組，按角色劃分屬于 dev 組。當要運作容器時，Kubernetes 叢集的 RBAC 政策會允許他在 Namespace A-dev 中操作。
• 例子二：一個使用者按架構域劃分既屬于 A 組也屬于 B 組，按角色劃分屬于 test 組。當要運作容器時，Kubernetes 叢集的 RBAC 政策會允許他在 Namespace A-test 和 Namespace B-test 中操作。

圖 2：企業組織架構與 Kubernetes 叢集

值得注意的是，IdP 中的組織架構代表 Kubernetes 管理者和使用者的組還是要嚴格分開以防止權限洩露。此外，當有任何組織架構變動時（例如，使用者從 Kubernetes 管理者變成使用者），Kubernetes 叢集需要能夠及時捕捉。

Identity 與 Service Mesh

其次，我們來看 Identity 是如何依據使用者/使用者組和相應的配置創造出不同的軟體運作環境的。當使用者通過 Kubernetes 開始運作容器後，容器所代表的微服務就交由 Service Mesh 來治理。如圖 3 所示，在 Istio 1.1+，在啟動 Pod 的時候，Pod Identity 會通過 SDS（Secret Discovery Service）擷取。

圖 3：Pod Identity 擷取流程

Pod 的 Identity 的格式會采取源自谷歌 LOAS（Low-Overhead Authentication Service）的 SPIFFE（Secure Production Identity Framework for Everyone）标準，spiffe:///ns//sa/以全局唯一辨別相應的 Workload；并且 Identity 相應的證書也會由 CA（Certificate Authority）來簽發。有了證書背書，當 Pod 可以與其它 Pod 通信時，就可以通過 mTLS 完成對通信鍊路加密。

更為重要的是，Service Mesh 可以通過 Istio RBAC 實作基于 Identity 的 RPC（Remote Procedure Call）ACL（Access Control List）。是以，當由有不同角色（例如，開發/測試/運維）的使用者來運作/部署同一個微服務時，因為所在組不同而擷取不同的 SPIFFE ID，即使在同一個 Kubernetes 叢集中，隻要設定合适的 Istio RBAC Policy，他們能運作的微服務也處于彼此隔離的環境中。

圖 4：Istio 下基于 Identity 隔離的環境

此外，一個組通常會擁有微服務的多組軟體子產品。當映射到 Kubernetes Namespace 時，對不同組的軟體子產品最好采用不同的 Service Account。這是因為，Pod 的 SPIFFE ID 的信任來自于 Kubernetes Service Account；一旦Service Account 被 compromise，它所造成的損失有限。

圖 5：Service Account 的隔離

Workload Identity 的實踐

阿裡巴巴正在全面推行 Service Mesh 的架構演進，這為我們在此場景下快速落地 Workload 的 Identity 及通路控制提供了很好的基礎。

圖 6：Service Mesh 架構下應用間通路控制

應用的身份以及認證統一由安全 Sidecar 統一提供，授權模型我們采用了 RBAC 模型，在 Sidecar 中內建了 RBAC Filter。RBAC 模型在大部分場景下都能滿足需求，但在項目推進過程中我們發現一種比較特殊的場景，比如 A 應用需要被所有的應用通路，會導緻政策無法描述。是以在這種場景下，我們考慮更新為 ABAC（Attribute-Based Access Control）模型，采用 DSL（Domain Specific Language）語言來描述，并內建在安全 Sidecar 中。

Identity 與軟體傳遞

此外，Identity 不僅僅展現在軟體研發、測試及運維，它還覆寫其他的方面。

鏡像管理

在雲原生範式下，代碼終将以鏡像的形式來使用。在關注構成鏡像本身代碼的安全性同時，我們還關心鏡像的來源（即相應代碼庫 URL），制作者（組）和标簽。線上上生産環境（其它環境可以放松這個限制）以容器運作鏡像時，我們需要確定鏡像是來自已知代碼庫，由合法的使用者（來自擁有代碼所有權的組）制作并有合适的标簽（例如，release）。是以，我們需要在鏡像的 metadata 中植入相關的 Identity 資訊以便應用相關的政策。

微服務部署

在雲原生時代，微服務部署所需的 yaml 配置往往是龐大繁瑣的。如前所述，Identity 結合 Kubernetes/Istio RBAC Policies 可以建立出不同的隔離環境以便于開發，測試和運維，但是也需要有相應的 yaml 配置來适配。然而，yaml僅僅隻是對一組可嵌套的描述，自身沒有任何複用，重載的計算機程式設計語言的特性。是以，我們需要使用雲原生場景下的 DSL 來友善的刻畫同一個微服務不同（例如，研發/測試/生産）環境下的配置。舉例來說，針對不同的環境，主要差別在于：1）Kubernetes Namespace 不同；2）所需的計算資源不同。是以，DSL 可以将各個環境相同的配置沉澱下來形成模版，在此基礎之上，對與環境相關的配置進行定制或重載以适配不同環境。

圖 7：DSL 下的微服務配置

通常來講，相對于微服務代碼變更，微服務配置變更屬于低頻操作。DSL 将微服務配置接管過來使得配置也像代碼一樣可重用、可驗證，大大降低因為配置及其變更帶來的錯誤。是以，所有的開發者可以對代碼進行更高速的疊代進而把代碼缺陷暴露在更早的階段。

Identity 與企業應用通路

阿裡巴巴已經内部已部分地落地了基于零信任的企業應用通路的架構，從以前簡單以員工的身份作為唯一且靜态的授權依據，擴充為員工身份、裝置、以持續的安全評估達到動态安全通路控制的新架構。

圖 8：企業應用的通路控制

在這種新的架構下，首先，我們選擇安全網關作為控制點，與阿裡巴巴 IAM（Identity Access Management）結合，對員工的身份以及接入的裝置進行認證，知道是否從對應的人和其對應的裝置請求接入；協定方面，員工裝置與安全網關之前，采用 HTTPS 對各種協定進行封裝，統一由安全網關進行代理通路後端的應用；其次，安全網關内置的 Access Control Engine 結合流量中的上下文（Context）對通路的請求做持續的模組化，對來自非可信、非認證裝置、或者異常的通路行為做實時的阻斷。

結語

随着網際網路應用由單體向微服務架構轉型，加之通路網際網路應用的移動裝置的繁榮，網絡辨別（例如，IP，Port等）已經不能作為穩定的 Identity 來辨別分布式系統中的實體，建立在此之上的邊界安全模型應對各種場景已經顯得力不從心。是以，對于不同實體（例如，人，裝置，服務等），Identity 需要由更能凸顯其本質的、有密碼學背書的穩定憑證（credential）來擔當。相應的，建立在此類 Identity 基礎之上安全政策有着豐富的語義來适配不同的場景：在研發、測試和運維微服務場景下，Identity 及其相關政策不僅是安全的基礎，更是衆多（資源，服務，環境）隔離機制的基礎；在員工通路企業内部應用的場景下，Identity 及其相關政策提供了靈活的機制來提供随時随地的接入服務。無論那種場景下，Identity 對分布式系統中不同實體劃分了有效的安全邊界，并提供隔離機制來提高資源效能和使用者體驗。

本書亮點

• 雙11 超大規模 K8s 叢集實踐中，遇到的問題及解決方法詳述
• 雲原生化最佳組合：Kubernetes+容器+神龍，實作核心系統 100% 上雲的技術細節
• 雙 11 Service Mesh 超大規模落地解決方案

“ 阿裡巴巴雲原生 微信公衆号（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公衆号。”