Google Cloud 的現代應用程式管理平台：Anthos 的用途是在跨雲端的環境中提供一致的開發、運營、安全體驗，Anthos 是專為那些希望能加速動態應用程式開發與部署、重視服務自動化、成本管理、安全控制的企業所設計。透過 Anthos，您只需建造一次 App，就能部署在各種不同的環境；也可以在合適的環境大規模自動化、現代化 App，並在混合雲和多雲的環境中一併管理。
Anthos 也能進化您維護 App 安全的方式，除了提供預設基礎的安全規範，它同時自動執行以下的安全操作：
- 隔離具有不同風險特徵的工作負載
- 只部署信任的工作負載
- 強制跨環境執行一致的使用規範
現今 App 在安全上的挑戰
現代 App 和過去相對較傳統的 App 主要有三個關鍵差異：「微服務架構」、「陳述式配置」、「高度自動化」。(更多 App 現代化資訊，請參閱應用程式現代化以及基礎設施服務與團隊的分離。) 若沒有辦法統一使用規範和達到跨環境管理工作負載，企業在推動現代化 App 的過程時將面臨安全挑戰。以下是現今 App 主要面臨的三大安全挑戰：
- 在混雜環境中應用一致的使用規範
- 保護軟體供應鏈
- 在共享平台保護多租戶環境
一致的使用規範
微服務既動態又短暫，您可以將微服務部署於多個不同的主機、叢集上，也能部署於雲端。當您一旦開始部署、停止部署、重新部署您的服務，即很難維持一致的安全規範，這就是所謂「叢集蔓生 (cluster sprawl)」所衍伸的問題。
使用配置管理工具來部署自動化且陳述式的規範，能幫助您在不同的環境中保持一致性。namespace 則提供跨服務的邏輯群組抽象 (logical group abstractions)，並讓管理員可以為特定的分租環境建立防護欄。此外，您可以透過繼承 (inheritance) 將組織層級的策略授權給租戶。在這樣新型的模式中，存取控制和使用規範的執行必須是陳述式和自動化的，才能符合組織對安全、風險、管理和合規性的控制需求。
軟體供應鏈安全
現代 App 因能持續整合和持續開發部署 (CI/CD)，服務也因此可以更快交付、更易擴展。您可以在 CI/CD 系統中從頭開始建構容器，但建構容器所帶來的高便利性、彈性，以及因其所產生的工作流程 (頻繁更換容器，以增加新功能或修補漏洞)，則將帶來新的安全挑戰。
每個容器都是從基本的作業系統 (OS) 開始建構，而從作業系統增生則是最常見安全議題，這通常會有不同的修補程度。舉例而言，您可能因為開發者可以下載新的元件和函式庫、佈建進容器，而帶來程式碼來源相關的資安問題。
雖然以開發人員為中心的部署模式能做到快速部署，但卻讓漏洞掃描和修補 (patch) 等安全維護工作難以執行，在缺乏標準化的狀況下，進而削弱管控能力。新模式需要一種方法來自動執行和部署受信任的工作負載的流程。
共享平台多租戶環境的安全性
容器的架構概念是多個容器運行在同一個主機上，並共享同一組機器的資源。這個架構具有可移植性並能有效利用資源，但同時也帶來一個不同的威脅模式：運行在叢集內的容器可能會有不同的風險特徵，但在共享同一個主機時，需要針對不同風險特徵進行對應的處理。舉例來說，您不能在這種新架構中運用基於傳統 IP 的授權。像是控制群組 (cgroups) 和 namespace 等容器分割機制、抑或是像 AppArmor 等安全模組，對具備其他風險特徵的工作負載是不足的。新的模式需要新的安全控制，以解決網路使用規範、工作負載隔離和服務認證的問題。
Anthos：現代化混合雲和多雲的安全性
您可以透過 Anthos 在跨環境實踐統一的使用規範、部署您所信任的工作負載，並隔離具有不同風險特徵的工作負載。
僅部署信任的工作負載
無論環境為何，您必須知道您所部署的容器映像檔是被信任的。任意的公開容器映像檔可能包含未被修補的漏洞，甚至是嵌入式的惡意程式，這會使您的企業遭受可預防的攻擊。下圖說明了企業該如何保障現代 App 資訊安全的方法。
(圖一) Source
透過採用最小的 OS 基本映像檔，並加入 App 所需的套件、函式庫和二進位文件。您可以降低這些容器映像檔的攻擊面：
- 使用專為容器設計的映像檔
- 確認映像檔有最新可用的修補程式
- 利用部署時檢查來確保供應鏈的完整性
Anthos 透過縱深防禦方法來保護亦受到攻擊的容器映像檔，代管的基本映像檔可以重複生成，並在上游有可用的修補程式時自動修補漏洞。GCP 的 distroless 映像檔是代管基本映像檔的最小替代方案，當您使用 distroless 映像檔作為您的基本映像檔來建立容器映像檔時，它僅包含您的 App 和 App 運作時所依賴的資源，進而大幅減少潛在的攻擊面。
在使用 Anthos 的過程中，您將體會到 Container Registry 本機漏洞掃描功能的好處。Container Registry漏洞掃描會尋找已知的漏洞 CVE 資料庫。在部署之前了解映像檔的漏洞，能避免開發人員將潛在高風險映像檔部署到生產中。掃描結果 (基於通用漏洞評分系統 CVSS 的分數) 會顯示嚴重性、修補程式的可用性以及有漏洞的套件名稱。
透過 Anthos，您也將受益於二進位授權 (Binary Authorization)。二進位授權是一個部署時間控制器，讓您可以定義要部署的容器映像檔的需求，並在映像檔不符合需求時停止部署。雖然每個組織對受信任的映像檔有不同的定義，但常見的需求包含漏洞掃描、合法建構驗證、測試團隊的 (QA) 審查。二進位授權已被整合入許多熱門的 CI/CD 工具中，並在部署映像檔前使用密碼證明來驗證需求。
藉由諸如託管基礎影像、Container Registry 掃描漏洞及二元授權等工具，您可以藉由將定義安全性的檢查納入開發過程，且使安全性成為應用程式生命週期的一部份，來「向左遷移安全性」。
隔離不同風險特徵的工作負載
為了提高資源效率，不同風險特徵的容器能夠共享相同的主機內核或機器節點叢集。您需要根據不同風險特徵來隔離和劃分應用程式，讓被授權的服務能彼此溝通並存取資源。下圖說明了 Anthos 如何提供整套安全功能，來隔離多層級的應用程式，包含主機、叢集、網路及服務。
(圖二) Source
- 您可以在叢集層上部署 GKE 私有叢集，由於這些叢集不具有公有 IP 位址，因此不會暴露在公共網路上。訪問主機也會受到限制。您可以授權外網來訪問主機。
- 您可以在叢集中使用 namespace 區分團隊及專案，namespace 提供了不同的 Kubernetes 身份，且您可以為記憶體及 CPU 分配資源額度。
- 在網路層中，您可以使用在第三層、第四層的 GKE 網路使用規範來控制對工作負載及 pods 的存取。以多租戶的觀點來看，這確保來自不同應用程式或不同租戶的 pods 無法通訊。
- 在應用程式層中，您可以使用 Anthos Service Mesh 在不同粒度層級上進行「服務到服務」及「使用者端到服務」的授權，包含 namespace 層、服務層、方法層。(關於零信任安全性、使用者訪問控制的更多資訊，請參考 BeyondCorp。)
- 在主機層中，GKE 沙盒為了在主機內核 (kernel) 及容器間的敏感或不信任的工作負載提供額外的隔離層。GKE 沙盒限制了應用程式可訪問的主機內核表面積，同時仍給予應用程式執行所需的操作。Anthos 促進了這種現代化，使企業能夠發展到一個僅部署信任的工作負載、隔離具不同風險特徵的工作負載，及在異構環境中實施一致使用規範的自動化安全操作平台。
跨環境執行一致的使用規範：Anthos Config Management
Anthos Config Management 可以讓您使用叢集運算子來管理單一叢集、多使用者叢集和多叢集 Kubernetes 部署作業，方法是使用儲存在 Git 存放區中稱為「設定」的檔案。部分設定為 Kubernetes 物件資訊清單；其他設定則不是物件資訊清單，而是提供 Anthos Config Management 本身所需的資訊。您可使用 YAML 或 JSON 的格式編寫設定。Anthos Config Management 會監看這些檔案的更新，並自動將變更套用至所有相關叢集。您可以利用設定視為程式碼的方法，管理 GKE 內部部署或 Google Kubernetes Engine 叢集的設定，並採用您管理部署在 Kubernetes 中的應用程式時所用的相同原則。您可使用 Anthos Config Management 進行以下作業：
- 在變更推送至線上環境前要求審查程式碼，並檢查是哪一個修訂版本造成設定變更。
- 降低「陰影作業」的風險，避免讓未經審查的變更推送至線上叢集，且有助於瞭解說明文件上的設定與線上環境之間的差異。您可以要求所有叢集設定的變更都透過 Anthos Config Management 進行推送，並鎖定 Kubernetes API 的直接存取權。
- 使用單一 Git 修訂版本將設定變更套用至數百個叢集，而不須手動編寫指令碼來執行數千項 kubectl apply 指令。
- 以套用至每個叢集的中繼資料為基礎，確保變更只會推送至所有相關叢集。
- 利用持續整合/持續部署 (CI/CD) 管道測試變更，並在測試通過時自動套用變更。
- 使用「還原後調查」策略來復原破壞性變更，並將線上叢集回復到良好的運作狀態，再修正發生問題的變更，並將其套用為新的修訂版本。這項策略可縮減因設定相關的服務中斷而造成的停機時間。
Anthos Config Management 會與 Git 存放區同步處理叢集的狀態。Config Management Operator 自訂控制器會監控 Git 存放區和叢集的狀態，確保它們在您所選的每個 Kubernetes 物件中保持一致。如果 Config Management Operator 無法將變更套用至某項資源，則該項資源會維持最後已知的良好狀態。Anthos Config Management 可以設定單一叢集或來自單一 Git 存放區的多個叢集。
必備條件
Anthos Config Management 使用 namespace、標籤和註解做為導入作業的核心部分，因此建議您先深入瞭解相關概念，再開始使用這項服務。在編寫設定之前，您必須先瞭解 Kubernetes 物件的必要欄位以及選用欄位，同時，Anthos Config Management 導入了一些新術語和概念，以下將為您介紹。
(一) 設定
「設定」是指 Kubernetes 設定宣告，以 YAML 或 JSON 格式編寫而成；Anthos Config Management 會讀取設定並套用至一或多個叢集，藉此在相關叢集中建立或設定 Kubernetes 物件或資源。設定會儲存在 Git 存放區 (另請參閱 Repo 的定義) 中。設定可以包含您能夠使用 kubectl edit 或 kubectl apply 套用至 Kubernetes 叢集的所有設定細節。您甚至還可以設定已存在叢集中的自訂資源。單一檔案中可以定義多項設定。詳情請參閱建立設定一文。
(二) Repo
Repo 是指儲存設定的 Git 存放區，其中包含 Anthos Config Management 本身的設定。所有設定都必須儲存在同一個 Repo 中。設定 Anthos Config Management 時，您必須設定 Repo、分支版本，以及 Anthos Config Management 監控變更的子目錄。Repo 的結構相當重要，我們會在使用 Repo 一文中進一步說明。
(三) 抽象 namespace 目錄
Anthos Config Management 提供一項稱為「抽象命名空間」的機制，可讓您將政策套用至多個相關 namespace 而不須複製設定，還能讓您針對指定 namespace 或一組 namespace 覆寫或擴展設定。抽象命名空間會使用存放區中的檔案系統式階層運作。在存放區中，namespaces/ 子目錄的目錄結構會採用一項類似檔案系統樹狀結構的機制，決定要將哪些政策套用至特定 namespace。多個 namespace 可以組成子目錄 (稱為抽象命名空間目錄)。詳情請參閱 namespace 沿用設定一文。
查看及驗證檔案
Anthos Config Management 提供一個 API。您可利用 nomos 和 nomos.exe 指令來使用這個 API，並簡化設定存放區和驗證設定的程序，詳情請參閱使用 nomos 指令一文。
即使現代應用程式架構衍伸了一連串新的安全挑戰，但您在面對這項改變的同時，也可以優化及自動化應用程式的安全維運工作流程。Anthos 促進了這種現代化，讓您能夠遷移到一個僅部署信任的工作負載、隔離具不同風險特徵的工作負載，及在異構環境中實施一致使用規範的自動化安全操作平台。
參考文獻
[1] Anthos: An Opportunity to Modernize Application Security
[2] Anthos Config Management documentation
