設計，實現與管理多雲的著陸區

32 min readJun 14, 2022

在本文中，我們將探討基礎知識，從管理著陸區(Landing zone)開始 —雲端環境的基礎。在企業開始遷移工作負載或在雲端環境中開發應用程式之前，企業需要定義這個基礎。著陸區的最佳實踐包括Azure中的Hub-spoken 模式、AWS 著陸區以及GCP中project的定義。在多雲中，這個著陸區擴展了多雲的概念和技術。

本文描述了如何為主要雲端平台(AWS/Azure/GCP，以下稱CSP)設計著陸區，並探討管理它們的 BaseOps 原則。我們將討論如何在 AWS、Azure 和 GCP 中設計著陸區，如何定義政策來管理著陸區，並更深入地了解如何處理這些著陸區的雲端帳號。我們還將討論，在某些平台上我們可以通過從一個控制台"編排與管理"不同的CSP。在本文中，我們將探討多雲環境中的基本概念，通過探討 IaC(Inafrastucture as Code) 和 CaC(Configuration as Code) 來學習如何從不同雲端平台上的資源中提煉出我們的政策，並了解雲端中劃定界線的必要性。

在本文中，我們將會介紹以下的主題：

了解 BaseOps 與基礎概念
建立一個多雲的著陸區與藍圖
使用政策來管理著陸區
對多雲來編寫政策
全域管理員 — 對分界的需求

了解 BaseOps 與基礎概念

BaseOps 可能不是所有人都熟悉的術語，儘管我們可以猜到它的含義：Basic Operation。在雲端環境中，這通常被稱為Cloud operation。 BaseOps 主要是關於通過優化使用主要CSP在不同層面上提供的雲端服務以最有效的方式來運行雲端環境：網路、運算、存儲，以及 PaaS 和 SaaS。

BaseOps 的主要目標是確保雲端系統可供企業使用，並且可以安全地用於執行以下操作：

監控"網路容量"與"正確的路由網路流量"
監控"運算資源容量"與依據業務需求來調整
監控"儲存資源容量"與依據業務需求來調整
監控資源的可用性，包括備份的health check與確保系統在有需要時能回復
監控系統的周邊和內部安全，確保資料完整性。
依服務等級進行全面的系統管理並使用KPI來按照業務約定的來管理
假設系統是盡可能的自動化，BaseOps 的一部分也將用於監控和管理。

說到底，這一切都與企業的服務品質有關。該品質由源自業務目標的服務等級和 KPI 定義。 BaseOps 必須能夠通過清晰的流程、熟練的人員和適當的工具來提供這種品質。

我們已經在其他文章探討了為什麼我們應該在雲端環境中部署系統的業務原因：

最終目標是具有靈活性、敏捷性以及成本效率。 這只有在我們標準化和自動化的情況下才能實現。 所有重複性任務都應該自動化。

識別這些作業並監控這些自動化任務是否以正確的方式執行，是 BaseOps 的一部分。自動化過程本身就是開發，但我們首先應該有 DevOps ，原因是我們可以執行開發團隊所發布的內容。就此而言，兩個團隊(BaseOp & DevOps)都有相同的目標：根據最佳實踐保護和管理雲端系統。

我們可以通過執行以下部分中提到的作業來實現這些目標。

定義與實現基本的基礎建設 — 著陸區

這是迄今為止 BaseOps 領域中最重要的活動。它是其他一切的基礎。著陸區是我們將託管"工作負載、應用程式和資料"的指定雲端平台上的環境。建立著陸區域的起始原則是它完全通過代碼來產生。換句話說，著陸區包含構成一致環境的構建區塊(building blocks)，我們可以在其中開始部署應用程式和資料功能，正如我們在多雲環境的雲端服務設計文章中討論的那樣，我們討論了建立我們架構之前要搭的鷹架。在本文的建立多雲著陸區和藍圖部分，我們將深入探討在不同的主要平台上建立著陸區：即 AWS、Azure 和 GCP。

對基本的基礎建設定義標準與政策

基本的基礎架構通常由可託管的網路和環境以及存儲資源組成。我們可以以HCI(Hyperconverged Infrastructure) 進行比較。它指的是一個實體機器，它包含運算節點、存儲設備和網路交換器，以確保運算節點和存儲可以實際通訊。我們需要的唯一補足的是允許這台HCI與外界通訊的路由器。雲端也不例外：基礎架構由運算、存儲節點和網路交換器組成。與HCI的主要區別在於 — 在雲端中，所有這些組件都是代碼。

但正如我們已經了解到的那樣，這還不足以開始。我們還需要一個區域，讓我們能夠從雲端與外部進行通訊並能連接。接下來，我們需要控制誰能存取環境。因此，基本的基礎架構將需要帳號以及以安全方式來配置基礎設施。即使在定義建立基本的基礎設施的標準和政策時，也有上百萬種選擇可以選。著陸區概念使快速入門變得容易得多。

根據經驗，基礎架構由五個元素組成：

網路
運算節點
儲存節點
帳號
防禦(資安)

好消息是所有 CSP 都同意這些是基礎設施的基本元素。更好的是，它們都提供code-based的組件來建立基礎架構。從現在開始，我們將這些組件稱為建構區塊(building blocks)。問題在於，它們在建構區塊的不同類型以及如何部署它們方面提供了很多選擇，例如通過藍圖、模板、代碼編輯、command line或通過它們各自的介面。

PS:關於甚麼是建構區塊，有興趣的讀者可以參考本部落格TOGAF的系列文章。

定義標準架構原則（架構模式和參考架構）
為組織的業務定義"參考架構的一種由外而內的思考方式"。從圓圈的角度考量架構。外圈是業務區，匯聚了所有業務需求和原則。這些驅動下一個內圈：解決方案區。這是我們定義解決方案組合的區域。例如，如果企業有分析大量資料（業務需求）的需求，那麼資料湖可能是一個好的解決方案。

解決方案區嵌入在外側的業務區和內側的平台區之間(如下圖)。例如，如果我們將 Azure(或AWS) 作為我們定義的平台，那麼我們可以將 Azure Data Factory(或S3)作為特定資料湖需求的解決方案。原則是從這些平台上，也可以是第三方PaaS和SaaS平台，將解決方案對應到業務需求。通過這樣做，我們建立了解決方案組合(solutions portfolio)，其中包含構成解決方案的特定構建區塊。

這個模型的核心 — — 最內圈 — — 是整合區，我們從這裡管理另一個圈中的整個生態系統。

安全性應包含在每一層或每一圈中。因此，整個模型的名詞由內在安全區(intrinsic security zone)設置：

上圖顯示了此模型以及需要資料分析的業務範例，其中 Data Factory和 Ddata Bricks作為來自 Azure 的工具。整個範圍構成了企業組合(Enrerprise portfolio)。

管理基本的基礎設施

即使我們只部署了一個著陸區，仍然有相當多的建構區塊需要我們從這一點開始進行管理。

對於網路，我們至少必須管理以下內容：

產生，設置，與管理虛擬網路(vNets, VPC, subnets, internet facing public zones, and private zone).
產生與管理網路路由，如NAT, NAC(network access control), ACL與流量管理．
產生與管理負載平衡， network peering，與VPN的network gateway或是網路專線．
產生與管理 DNS
網路監控
偵測，調查與解決網路功能相關的事件

對於運算，我們至少必須管理以下內容：

VM/container/serverless的產生，設置，與維運．如果是VM通常包含各類的OS
偵測，調查與解決運算功能相關的事件．
Patch management
維運上的備份(full/iterative/snapshots)
監控，日誌紀錄，health check，與主動性的檢查和維護

我們需要注意，雲端環境中的運算涉及的不僅僅是VM。它還包括container、container orchestration、functions和serverless運算等內容。但是，在著陸區，這些原生服務往往不會被立即部署。我們可能會考慮將容器平台部署為基礎架構的一部分。也要記住，在雲端中，我們確實看到了從 VM 到container的強烈轉變，因此我們應該在設置著陸區時為此做好準備。

在大多數情況下，這將包括設置 K8S cluster。在 GCP 中，這是通過 GKE 完成的，我們在其中創建一個GCP project中的VPC來託管 GKE cluster。 AWS 通過 EKS 提供自己的cluster服務。在 Azure中，這是 AKS。

接下來，我們將必須管理雲端帳號並確保我們的著陸區 — — 雲端環境及其所有建構區塊 — — 是安全的。帳號管理涉及建立需要存取雲端環境的帳號或帳號群。對大型企業來說這些通常會在 Windows AD 中建立。

在本文的全域管理員 — 劃分的必要性部分，我們將更深入地了解管理員帳戶和全域管理員帳戶的使用。 "安全性與帳號、IAM"緊密相關，但也與系統強化（保護系統免受外部威脅）、端點保護和漏洞管理等事物密切相關。從第一天開始，我們必須在所有層面上都設置安全措施，以防止、偵測、評估和緩解任何安全缺口。

定義與管理基礎設施的自動化工具與流程(IaC & CaC)

在雲端，代碼就是一切。我們不再需要購買實體機器；我們只需在代碼中定義我們的硬體。這並不意味著我們不必管理它。為了以最有效的方式做到這一點，我們需要一個master code repo。這個 repo(儲存庫) 將包含定義基礎設施組件的代碼，以及如何配置這些組件以滿足我們在安全性和合規性方面的原則。這就是通常所說的desired state也稱為宣告式。

AWS、Azure 和 GCP 提供了 IaC 和 CaC 的本地工具，以及自動部署所需狀態的工具。在 Azure 中，我們可以使用 Azure DevOps 和 Azure automation，它們都可以使用 ARM(Azure Resource Manager)。 AWS 提供 CloudFormation，而 GCP 提供 Cloud Resource Manager和 Cloud Deployment Manager。這些都與各自的平台相關聯，但市場還提供第三方工具，這些工具往往與這些平台無關。我們將在本章後面部分探討一些第三方的工具。

如果是 source code management, 我們可以使用的工具如 GitHub, Azure DevOps, AWS CodeCommit與 GCP Cloud Repositories.

定義與實施監控與管理工具

我們已經討論了監控的必要性。下一步是定義我們可以使用哪些工具來執行這些任務。同樣，雲端平台提供原生工具：Azure Monitoring、Application Insights 和 Log Analytics； AWS CloudTrail 和 CloudWatch；和 GCP Stakedriver monitoring。當然，還有大量第三方可用，例如 Splunk 和 Nagios。第三方工具有個很大的優勢，因為它們可以獨立於底層平台運行。本文不會討論工具 A 優於工具 B。作為架構師，我們必須決定什麼工具是符合需求的當然還有預算，但僅此而已。

資安是一個特殊的話題。雲端平台在為其平台建立廣泛的資安監控方面付出了相當大的努力。監控不僅僅是偵測；它還與觸發緩解措施有關。當涉及到安全性時尤其如此，因為只有偵測到漏洞肯定是不夠的。實際上，從偵測到弱點或漏洞到被利用之間的時間可能只有幾秒鐘，這使得有必要快速行動。這就是 SIEM 發揮作用的地方。 SIEM 系統發展迅速，智慧解決方案(SOAR與ML)通常是系統的一部分。

Azure Sentinel 就是一個例子，它是一種 Azure 原生 SIEM 解決方案：它與 Azure Security Center(存儲和管理策略)一起作業，但它還對它在企業於 Azure中上託管的環境中看到的行為進行分析。最後，它可以自動觸發動作。例如，它可以阻止前一分鐘從英國登錄，下一分鐘從新加坡登錄的帳戶 — — 如果沒有瞬間移動，這是不可能的。

換句話說，監控系統確實變得更加複雜，並且進化的跟光速一樣快。

支援性的操作

最後，一旦我們考量了以上的所有這些，我們需要弄清楚誰將執行所有這些作業。我們將需要具備適當技能的人員來管理我們的多雲環境。正如我們在其他文章說過的，真正的 T 型工程師或管理員並不存在。那就是要找一頭有五隻腳的牛。大多數企業最終都會有一群開發人員和維運人員，他們都具有通用和更具體的技能。一些廠商將此稱為 CCoE(雲端卓越中心)，並將其標記為該企業雲端之旅或雲端適應過程中的重要一步。此階段的一部分將是我們確定此 CCoE 應具有的角色並讓 CCoE 的成員參與其中。團隊需要能夠構建和管理環境，但他們也將在宣揚新的雲原生解決方案方面發揮重要作用。關於CCoE更多的介紹，可以參考這一篇AWS的介紹．

建立一個多雲的著陸區與藍圖

所有主要的 CSP 都提供了一種方法，可用於在各自的平台上建立著陸區。在本節中，我們將探討 AWS、Azure 和 GCP 的著陸區概念。

設定Azure的著陸區

Azure 中的著陸區是 CAF(Cloud Adoption Framework) 的一部分，它實現了一組的雲端服務，以幫助我們開始構建或遷移工作負載到 Azure 平台。著陸區創建了所有必要的構建區塊(building block)，使企業能夠開始使用雲端平台。

當我們討論雲端的鷹架時，我們之前就用建造房屋來類比。考慮著陸區是空房子。房子有地基；也就是說，一個大門可以進入然後我們有可以放置家具的房子和房間。這些房間的設計旨在滿足特定需求。廚房有烹飪設備的接口和自來水的水龍頭。浴室也是如此：它有水龍頭、淋浴器、浴缸，還有一個在弄濕時不會損壞的地板。我們可以將其與著陸區進行比較：它已經為特定用途設置了房間，例如滿足外部網路的需要。

準備這些房間以供使用是微軟所說的refactoring(重構)。 CAF 指導企業設置安全、身份和訪問管理、命名約定、成本管理等。所有這些主題都部署為當時著區域的一部分。一旦我們完成著陸區的構建，我們將擁有一個安全的基礎平台，並定義了命名和標記約定，其中 RBAC(Role-Based Access Control)已經就位，我們清楚地了解我們在平台中產生的成本 .

現在，我們還需要什麼呢？

首先，我們需要訂閱 Azure。接下來，我們需要部署房間，即我們將託管系統的環境中的不同部分。在 Azure 中，我們通常部署 Hub-and-Spoke模型。這源於 Azure 提供共享服務，這些服務在不同的房間中使用，例如監控和備份服務。這些共享服務著陸在Hub。 Spoke連接到Hub，以便它們可以從那裡使用共享服務，而不必將所有共享服務分別部署到不同的Spoke中。

著陸區由代碼組成：它是 IaC，因此它從一開始就完全從代碼來驅動 Azure 架構。為此，它使用 JSON 格式的 ARM 模板。我們實際上可以為代碼設計藍圖，以便我們可以以非常一致的方式輕鬆啟動新的spokes。例如，該藍圖將包含顯示spoke如何連接到Hub以及如何使用共享服務的代碼。 Azure 提供了各種簡單的著陸區藍圖，讓我們快速入門。但是，請檢查藍圖是否滿足我們特定業務的合規性和安全性要求。

著陸區藍圖將提供以下內容：

virtual network中的subnets(帶有gateway)、Azure 防火牆和 Azure Bastion server（一個 jumpbox，它是管理員用來進入雲端環境的管理服務器）
用於記錄和監控的storage account
Azure Migrate project

我們要認知到，此著陸區尚不適合託管敏感資料或關鍵任務應用程式。藍圖是在訂閱已與 Azure AD insatnce關聯的假設下部署的。此外，著陸區藍圖的假設是沒有應用任何 Azure policies。換句話說，我們將有一個空房子和幾個空房間，我們仍然需要自己進行裝飾，這意味著我們必須實施baseline和policies。

這讓我們開始通過重構著陸區並添加服務來提高效能、可靠性、成本效率和安全性，我們將準備好實際託管工作負載：

上圖顯示了 Azure 中著陸區的基本設置，其中包含一個用於託管通用服務的Hub和兩個用於託管工作負載的spokes。這些spokes有兩個subnet：一個用於管理，一個用於實際工作負載，例如應用程式。更多關於Azure 著陸區的介紹可參考 Azure 官方網站．

設定AWS的著陸區

AWS 提供 AWS 著陸區作為基於 Node.js runtime的完整解決方案。與 Azure 一樣，AWS 提供了許多解決方案，以便我們可以設置環境。所有這些解決方案需要設計決策。為了節省入門時間，AWS 著陸區設置了一個準備就緒的基本配置。為此，AWS 著陸區部署了所謂的 AWS AVM(Account Vending Machine)，它使用 SSO(Single sign-on) 產生和配置新的account。

要掌握這一點，我們必須了解 AWS 環境的配置方式。它有點類似於 Azure 的 Hub-and-spoke模型，但不是 Hub-and-spoke，而是 AWS uses account。 AWS 著陸區包含四個遵循 AWS 的 CAF 的account：

Organization account:這是用於控制著陸區的多個子帳號和配置。它還包括 S3 bucket中的所謂manifest file。 manifest file為region和Policy設置參數。這些manifest file指的是 AWS CloudFormation，這是我們在雲中端與 Azure 中的 ARM 類似的服務。 CloudFormation 有助於在 AWS 中創建、部署和管理資源，例如 EC2 instance和 RDS。它就是AWS的IaC。
Shared services account：預設情況下，著陸區通過 SSO 管理關聯帳號。 SSO 整合和 AWS managed AD 託管在共享服務帳號中。它會自動與創建著陸區的 VPC 中的新帳號建立對等關係。 AVM 在這方面發揮了重要作用。
Log archive account:AWS 著陸區使用 CloudTrail 和Config Logs。 CloudTrail 監控並記錄我們創建的 AWS 環境中的帳號活動。它基本上保留了部署在 VPC 中的基礎設施中發生的所有操作的歷史記錄。它與 CloudWatch 的不同之處在於CloudTrial比較像是雲端的活動稽核紀錄。 CloudWatch 監控 AWS 環境中的所有資源和應用程序，而 CloudTrial 監控帳號中的活動並將這些活動記錄在 S3 bucket中。
Security account:該帳號擁有密鑰庫(存儲帳號的目錄) — — 用於著陸區中的跨帳號角色和 AWS 提供的兩項安全服務：GuardDuty 和 AWS SNS。 GuardDuty 是用於威脅偵測的 AWS 服務，SNS 可以發送安全通知。著陸區實施和初始security baseline，包括（除其他外）config files的中央存儲、IAM 密碼政策的配置、威脅偵測和著陸區通知。對於後者，CloudWatch 用於在例如 root account登錄失敗的情況下發送告警。

下圖顯示了 AWS 中著區域的設置：

我們尚未討論的一件事是 AVM(Account Vending Machine)。這對設置著陸區起著至關重要的作用。 AVM 使用預定義的網路和security baseline在著陸區啟動基本帳號。在底層，AVM 使用 Node.js 模板來設置 OU，之前描述的帳號是使用preconfigured settting部署的。啟動的組件之一是 AWS SSO directory進行federation存取 AWS Account。更多關於AWS 著陸區的介紹可參考 AWS官方網站．

設定 GCP的著陸區

GCP 與 AWS 和 Azure 也提供了Hub-and-Spoke模型，在Hub這個部分的著陸區GCP稱為shared VPC。Shared VPC是由GCP organization Admin來管理的．它可以連結多個不同Project的多個運行workload的VPC．其中Service Project Admin可以管控這個shared VPC的網路相關設定(routes/subnets/firewalls)．

在這著陸區中， GCP讓企業能夠進行以下三種主要工作：

為網路管理、稽核和訪問控制實施least privilege的security best practices。 shared VPC 管理員可以將網路管理任務委派給shared VPC中的network admin和security admin，而不允許service project admin進行影響網路的變動。 service project admin只能建立和管理使用shared VPC 網路中的instance。
在委派管理職責的同時，在網路等級為組織中的多個service project應用和實施一致性的訪問控制策略。例如，service project admin可以是其project 中的compute instance admin，建立和刪除使用shared VPC 託管project 中已subnet的instance。
使用service project來分隔預算或內部成本中心。

上圖為一個簡單的shared VPC與非shared VPC的著陸區的簡單對比．我們可以看到如果是shared VPC，在service project A與B的instance是借用了shared VPC的 IP. 但實際的instance還是運行在自己的project中．更多的shared VPC可參考GCP文件。

PS:關於三大公有雲的CFA(cloud adoption framework)請參閱本部落格CFA系列文章。

使用政策(Policy)來管理著陸區

當我們在雲端平台上作業時，我們使用代碼。我們在雲端中所做的一切都是軟體和代碼定義的。這使得雲端基礎設施絕對非常敏捷，但這也意味著我們需要一些嚴格的政策來管理代碼，從定義我們的著陸區或基礎環境的代碼開始。與 IT 中的一切一樣，它需要維護。在傳統的資料中心和系統中，我們有可以更新和升級系統的維護時間區間。在雲端中，事情的運作方式略有不同。

首先，CSP 在需要時進行維護。他們無法就遍布全球的數萬個客戶的維護窗口達成一致。他們只是做任何需要做的事情來保持平台健康，為改良和新功能的發布做好準備。企業不想受到這些維護活動的影響，因此他們必須確保他們的代碼始終是安全的。

我們需要考慮的下一件事是企業在雲端平台上部署的系統，在他們自己的雲端中。這些資源也需要維護。如果我們正在運行VM，我們將需要不時地修補它們。在這種情況下，我們正在修補代碼。我們希望通過這些活動確保管理員不會意外覆蓋某些安全設置或更糟的是，刪除資源實現的特定功能所需的硬碟或任何關鍵代碼。這是我們在設置著陸區時必須從一開始就關心的事情。從那時起，我們必須開始管理。為此，我們使用標準政策和管理工具。

管理AWS的基本操作

AWS 提供 CloudFormation Guardrails。它使我們的環境保持正常。 Guardrails 具有四個主要功能，它以 JSON 格式設置政策。為了創建政策，AWS 提供了Policies Generator。在Policies Generator中，我們首先定義政策的類型，然後定義條件，即何時套用政策：

Termination protection:
在這裡，AWS 談到了stack甚至nested stacks。 stack只是 AWS 資源的集合，可以從 AWS 管理控制台作為一個單元進行管理。 Stack的範例可以是包含前端服務器、使用 S3 bucket的 DB instance和網路規則的應用程式。啟用Termination protection可防止這個stack被意外刪除。 Termination protection預設是沒開啟的，所以我們需要從管理控制台或者使用命令行來啟用它。
Deletion policies:
在Termination protection將整個stack作為範圍的情況下，Deletion policies針對特定資源。要啟用此功能，我們必須在 CloudFormation template中設置“DeletionPolicy”屬性。現在，這項政策具有很多功能。例如，該政策有一個保留選項，因此每當刪除資源時，它仍作為屬性保留在我們的 AWS 帳號中。我們還可以讓 CloudFormation 在資源被刪除之前對其進行快照。在合規性和稽核方面對刪除策略有一個很好的紀錄保存是絕對值得的。 請記住，Deletion policies是按每個資源設置的。
Stack policies:
這些政策設置為定義整個stack或資源組的操作。一個操作可能是更新所有DB instance。
IAM policies:
這些政策定義了access control；也就是說，誰可以在什麼時候做什麼？可以為整個stack、特定資源組甚至單個資源設置高精細度的access control，並且只允許特定作業定義user是那些role。換句話說，這是我們管理 RBAC 的地方。

管理Azure的基本操作

當我們查看 Azure 時，我們必須在 Azure 用於著陸區中稱為 TDD(test-driven development) 的服務。 TDD 以軟體開發而聞名，因為它旨在提高軟體代碼的品質。正如我們已經討論過的，Azure 中的著陸區正在通過重構過程擴展，這是一種構建著陸區的迭代方式。 Azure 提供了許多支援TDD 的工具，並在重構著區域的過程中提供如下協助：

Azure Policy:
這將根據業務規則驗證將在 Azure 中部署的資源。業務規則可以定義為成本參數或閾值，以及安全參數，例如檢查資源的強化或與其他資源的一致性。例如，他們可以檢查某個 ARM template是否已用於部署。還可以將政策組合在一起以形成可以分配給特定範圍（例如著陸區）的計畫。政策可以包含操作，例如拒絕對資源的變更或在驗證後進行部署。 Azure Policy提供了可專門用於執行 TTD 的內建計劃：它將根據業務規則驗證著陸區中的計劃資源。成功的驗證將導致所謂的完成定義，並接受已部署的資源。
Azure Blueprints:
借助Blueprint，我們可以將政策、計劃和部署配置組合到一個package中，以便在企業想要在不同訂閱中部署多個著陸區時重複使用它們。 Azure 提供了各種blueprints sample，包括用於測試和部署template的政策。好消息是這些可以通過 Azure DevOps 輕鬆導入，因此我們從一開始就擁有一個具有一致代碼存儲庫的 CI/CD pipeline。
Azure Graph:
Azure 著陸區的部署基於重構的原則。因此，在各種迭代中，我們將擴大我們的著陸區。由於我們是按照 TTD 的原則作業，這意味著我們必須測試迭代是否成功實施，資源是否以正確的方式部署，以及環境是否具有互通性。對於這些作業，Azure 提供了 Graph。它創建test set來驗證著陸區的配置。 Azure Graph 附帶查詢範例，因為開始使用 Graph 使用的setting 和coding可能會變得很麻煩。
Azure quickstart templates:
如果我們真的想快速上手，我們可以使用quickstart templates，它為著陸區本身及其相關資源的部署提供default setting。

管理GCP的基本操作

正如我們所見，GCP 在公有雲和著陸區方面可能會有所不同。這源於Google的概念觀點，它更專注於使用 K8S 的容器技術。儘管如此，GCP 在為部署在 GCP 上的環境設置策略方面提供了廣泛的可能性。在大多數情況下，這些策略由使用 IAM policies的組織和資源組成：

Organizations:
在 GCP 中，我們使用constraint來設置policies。 constraint是添加到service definition中的屬性。舉個例子，我們將使用將 VM 部署到 GCP project的Compute Engine。在 Compute Engine 中，預設情況下無法login到 OS。我們可以啟用它並設置一個所謂的Boolean constraint：一個陳述或邏輯表達式是True/False。在這種情況下，我們將 Compute Engine設置為 true。接下來，我們必須設置一個政策來防止這個login被禁用：constraints/compute.requireOSLogin. GCP 中的許多政策和constraints都是根據這個原則作業的。
Resource policies:
Cloud IAM policies以 JSON 或YAML 格式為所有 GCP 資源設定access control。每個政策都由binding、audit configuration和metadata定義。每個 binding 由一個user、一個role和一個condition組成。 user可以是任何身份。我們之前設置的內容：在雲端中，基本上一切都是一個身份(identity)。這可以是user，也可以是我們雲端環境中具有特定作業的資源，以便它們可以訪問其他資源並有權執行這些任務。因此，成員(member)是一個身份：user、service account、resource或resource group。成員綁定到定義成員擁有的權限的role。最後，我們必須確定成員在什麼條件下可以執行其role以及哪些constraint是有效的。這共同構成了一個binding。

但是，binding只是policies的一部分。我們還有一個 AuditConfig 來記錄log和metadata。 metadata中最重要的field是 etag。 etag 用於保證在project中的各種資源中以一致的方式使用policies。如果在一個系統上更改了policies，則 etag 可確保policies保持一致。不一致的policies將導致資源部署失敗。

Policies可以有多個binding，並且可以在 GCP 內的不同等級上設置。但是，這是存在限制的。例如，GCP 允許每個policies最多包含 1,500 個成員。因此，請徹底查閱文件，包括使用policies的最佳實踐。

對多雲來編寫政策(policies)

到目前為止，我們已經了解了在幾個主要雲端平台中設置policies的不同方式。現在，我們在多雲中真正想要的是一個單一的儲存庫，我們可以在其中存儲和管理我們所有的policies。我們可以這樣做嗎？從技術角度來看，我們大概可以：所有CSP都支援 JSON 作為一種編寫格式。問題是這些平台有不同的部署政策概念。而這個問題的解決方案是什麼？

要考慮解決方案，我們必須從代碼本身的層次抽象邏輯開始思考。這是什麼意思？Policies有一定的邏輯。例如，從安全角度來看，我們可以定義我們環境中的所有VM都必須按照 CIS (Center for Internet security)的指導方針進行強化。VM的類型是甚麼沒差，它運行的OS類型或VM託管在什麼平台上也是沒差。邏輯只是說需要通過遵循 CIS 框架的建議來強化 VM。它完全從部署 VM 的代碼中抽像出來。如果我們這樣做，我們可以將policies本身存儲在單一個儲存庫中。然後，我們唯一需要做的就是加上將 VM 部署到目標雲端平台所需的特定代碼。

這基本上就是 HashiCorp 的 Terraform 所做的。 Terraform 從代碼中抽像出policies，以便它可以從單一來源在各種雲端平台上部署IaC。為此，它使用了所需狀態的定義：啟動基礎設施資源的代碼完全從該資源的實際配置中抽像出來。需要注意的是，Terraform 是冪等(idempotent)和收斂的(convergent)，這意味著只應用所需的變更以將環境返回到所需的狀態。

這一點將幫助我們更好地理解 DSC(desire state configuration)。首先，DSC 通常與 Microsoft PowerShell 相關聯。這是有道理的，因為 DSC 確實是隨 Windows Server 2012 R2 所帶出來的。然而，如今，Desired state這個術語被更廣泛地用於從基礎設施的實際配置中抽象IaC。它通常用於 CI/CD pipeline。在這裡，開發團隊可以構建必要的系統，當這些系統投入生產時，所需的狀態就會得到部署。一個範例是安裝備份代理或將資源置於監控之下。下圖顯示了desired state的簡化模型：

Terraform 使用的語法允許我們完全抽象resources 和providers。它定義了可以容納任何類型資源的區塊(blocks)，從 VM 到容器，還包括某些服務，例如 DNS。這是在 HCL(HashiCorp Configuration Language) 中定義的。

下一步是將這些區塊部署到我們的目標雲端平台。這是通過在該雲端中初始化專案來完成的。為此，使用 Terraform init 命令。 init 將讀取 Terraform configuration files並導入連接到各種雲端和服務所需的提供程序。下一步是使用 Terraform plan 命令，該命令用於創建執行計劃。這決定了實現configuration file中指定的所需狀態所需的操作。最後一步是使用 Terraform apply 命令，該命令部署操作以達到desired state。

Terraform 現在會將這些區塊應用到雲端中，同時創建一個所謂的state file。這個state file用於將未來變更套用到基礎架構：在將變更套用到由 Terraform 自動創建的執行計劃中之前，它會運做一個實際環境的refresh以更新state file。這樣，Terraform 始終保存實際部署代碼的最新版本，並始終保持環境同步。

如果我們是熟悉 Chef 或 Puppet 等configuration tools，我們會看到Terraform 和其他一些工具的功能存在一些重疊。最大的不同是 Terraform 實際上提供了新的基礎設施資源，而大多數其他工具更側重於將configuration setting加到已經部署的資源中。這並不意味著configuration tools沒有用；相反。這些工具還有其他使用場景；沒有好壞之分。

多雲的關鍵是單一的控制儀錶板。然而，這是一個複雜的領域。 ServiceNow 等公司的開發目標是創建平台，企業可以通過該平台從一個控制台進行多雲編排。它包含一個用於政策和合規性管理的產品，該產品提供了一個用於創建和管理跨雲政策的集中流程。

我們可以部署與不同雲端平台無關的代碼和政策。但是，它確實需要工具。在本節中，我們在撰寫本文時探討了市場上的一些工具。所有這些都需要對從功能和政策中抽像出基礎設施資源有透徹的了解，從而產生所需的資源狀態。

全域管理員 — 對分界的需求

通常，當我們談論雲端模型中的劃分時，我們指的是責任矩陣或責任劃分：誰負責 IaaS、PaaS 和 SaaS 運算中的什麼部分？下圖顯示了這個矩陣的基本原理：

但是，我們需要在多雲中使用更精細的模型。我們在本文中一直在討論政策(policies)，到現在為止，我們應該得出的結論是，在我們的多雲環境中，要劃出一些非常明確的界限並不容易。只需查看solution stack — — 即使在 SaaS 解決方案中，解決方案也可能需要遵守某些安全和(或)合規政策。甚至諸如OS之類的東西也可能已經在強化方面引起了問題：是否允許來自 PaaS 提供商的監控VM中的agents？我們可以將它們與我們首選的監控解決方案一起運作嗎？或者這會對我們的系統造成過多的overhead？總之，多雲的世界並非非黑即白。相反，多雲具有廣泛的彩色方案可供使用。

那麼，我們如何獲得適用於我們的分界模型呢？這就是架構。首先，我們不需要遍布整個企業雲端運算的全域管理員。這是多雲中的一個主要缺陷。我們都知道這種情況：需要全域管理員權限才能執行某些操作的資料庫管理員，或者更糟糕的是，需要具有此類角色的service account的解決方案。它是全域管理員。當談到為什麼系統需要環境中可能的最高訪問權限時，請質疑這些request並挑戰軟體廠商或開發人員。

這就是雲端部署的起點：Policies。在這種情況下，一個好的做法是 PoLP(Policy of Least Privilege)。這表明每個identity都被授予執行分配給這個identity的工作所需的最小訪問權限。請記住，在這種情況下，identity不必是user：它可以是環境中的任何資源。當我們談論user時，我們將其稱為 LPUA(Least-Privileged Account or Access)。 PoLP 有助於保護資料，因為只有在明確授予user或identity訪問該資料時才能訪問資料。但還有更多理由堅持這項政策。它還有助於保持系統健康，因為它可以最大限度地減少系統中的風險或故障。這些故障可能是無意的，也可能是惡意行為的結果。我們應該始終遵循最小權限規則。

關於這個最基本的原則，在這個階段還需要考慮更多的因素。這些考慮因素轉化為控制，並隨之轉化為作為 BaseOps 一部分的可交付成果，因為它們絕對是多雲中基本原則的一部分。下表顯示了這些控制項和可交付成果：

總結

在本文中，我們在不同的主要雲端平台上設計並設置了我們的著陸區。我們了解到，基本原則可能是可比的，但著陸區概念的實際底層運作是不同的。接下來，我們探討了IaC和CaC的原則。借助 Terraform 等工具，我們可以使用從資源代碼中抽像出來的配置政策，從一個儲存庫管理多雲。然後，我們學習了如何定義政策以及如何應用這些政策來管理我們的著陸區。最後，我們了解到在多雲中需要一個冗餘的分界模型。這一切都構成了 BaseOps 的概念：正確掌握基礎知識。