CloudFormation Hook整合Policy As Code實踐

– 9 分鐘閱讀

隨著雲端原生應用程式和基礎設施即程式碼的普及，對於 IaC 的安全性與合規性要求也日益提升。本文將介紹如何利用 AWS CloudFormation Hook 與 Policy as Code 工具，例如 OPA 和 Conftest，來提升 IaC 的安全性及管理效率。首先，我們將引導讀者瞭解如何註冊和使用 AWS CloudFormation Hook，並示範如何結合 OPA 進行資源驗證。接著，我們將探討如何安全地呼叫 OPA Server，並分享一些實務上的最佳作法。最後，我們將探討如何使用 Conftest 來驗證 Terraform HCL 檔案，確保其符合組織的規範和安全性策略。

使用AWS CloudFormation Hook與Policy as Code的整合實踐

AWS CloudFormation（CFN）Hook是一種強大的工具，允許開發者在資源建立、更新或刪除之前進行預先驗證或處理。在本章中，我們將探討如何使用AWS CFN Hook與Policy as Code（PaC）工具（如Open Policy Agent，OPA）整合，以提升基礎設施即程式碼（IaC）的安全性和可管理性。

註冊AWS CloudFormation Hook

首先，我們需要使用cfn submit命令來建立並註冊Hook型別到AWS CFN私有登入檔。以下是一個範例命令：

$ cfn submit --set-default

執行成功後，命令會傳回一個包含Hook型別ARN和版本ARN的JSON回應：

{
  "ProgressStatus": "COMPLETE",
  "Description": "Deployment is currently in DEPLOY_STAGE of status COMPLETED",
  "TypeArn": "arn:aws:cloudformation:<AWS_REGION>:<AWS_ACCOUNT_ID>:type/hook/PaC-Book-Hook",
  "TypeVersionArn": "arn:aws:cloudformation:<AWS_REGION>:<AWS_ACCOUNT_ID>:type/hook/PaC-Book-Hook/00000001",
  "ResponseMetadata": {
    "RequestId": "13daf344-bd14-4772-a842-fdb879d776d1",
    "HTTPStatusCode": 200,
    "HTTPHeaders": {
      "x-amzn-requestid": "13daf344-bd14-4772-a842-fdb879d776d1",
      "date": "Sat, 09 Sep 2023 17:33:23 GMT",
      "content-type": "text/xml",
      "content-length": "657",
      "connection": "keep-alive"
    },
    "RetryAttempts": 0
  }
}

內容解密：

此命令用於註冊一個新的CloudFormation Hook，並將其設定為預設版本。其中：

  • cfn submit是CloudFormation提供的用於提交和註冊Hook的命令。
  • --set-default引數表示將新註冊的Hook版本設定為預設版本。
  • 傳回的JSON回應包含了Hook的ARN、版本ARN以及其他相關資訊。

列出已註冊的CloudFormation Hook

註冊成功後，可以使用AWS CLI命令列出已註冊的CFN Hook：

$ aws cloudformation list-types

回應結果如下：

{
  "TypeSummaries": [
    {
      "Type": "HOOK",
      "TypeName": "PaC::Book::Hook",
      "DefaultVersionId": "00000001",
      "TypeArn": "arn:aws:cloudformation:<AWS_REGION>:<AWS_ACCOUNT_ID>:type/hook/PaC-Book-Hook",
      "LastUpdated": "2023-09-09T17:33:23.094000+00:00",
      "Description": "Hook to prevent unwanted EKS changes"
    }
  ]
}

內容解密：

此命令用於列出當前AWS帳戶下已註冊的CloudFormation Hook。其中：

  • Type欄位表示Hook的型別。
  • TypeName是Hook的名稱。
  • DefaultVersionId表示預設版本的ID。
  • TypeArn是Hook的ARN，用於在其他AWS服務中參照該Hook。

使用AWS CloudFormation Hook進行資源驗證

AWS CFN Hook支援三種操作：CREATE、UPDATE和DELETE。開發者可以針對特定的資源型別（如AWS::EKS::Cluster）編寫Hook邏輯。例如，以下是一個Python範例，用於在建立EKS叢集前進行驗證：

{
  "additionalProperties": false,
  "description": "Hook to call validate EKS cluster before CFN creation",
  "documentationUrl": "https://example.com/hooks/docs",
  "handlers": {
    "preCreate": {
      "permissions": ["secretsmanager:GetSecretValue"],
      "targetNames": [
        "AWS::EKS::*"
      ]
    }
  },
  "typeName": "PaC::Book::Hook"
}

內容解密：

此JSON組態定義了一個CloudFormation Hook，用於在建立EKS叢集之前進行驗證。其中：

  • handlers欄位定義了不同操作的處理邏輯，例如preCreate表示在資源建立前執行的邏輯。
  • targetNames欄位指定了該Hook適用的資源型別，例如AWS::EKS::*表示所有EKS相關資源。
  • permissions欄位列出了執行該Hook所需的許可權。

將Policy as Code與AWS CloudFormation Hook整合

為了避免為不同的資源和操作編寫多個自定義Hook，我們可以將通用的PaC工具（如OPA）與AWS CFN Hook整合。這樣可以減少重複工作，提高可重用性。

圖表說明

  graph LR
    A[AWS CloudFormation] -->|呼叫Hook| B[AWS CFN Hook]
    B -->|驗證請求| C[OPA Server]
    C -->|傳回驗證結果| B
    B -->|根據驗證結果處理資源| A

圖表翻譯： 此圖展示了AWS CloudFormation與OPA整合的流程：

  1. AWS CloudFormation在執行資源操作前呼叫已註冊的Hook。
  2. AWS CFN Hook將驗證請求傳送給OPA Server。
  3. OPA Server根據預先定義的策略進行驗證，並傳回結果。
  4. AWS CFN Hook根據OPA的驗證結果決定是否繼續執行資源操作。

安全呼叫OPA Server

為了安全地呼叫OPA Server，我們可以在AWS Secrets Manager中建立一個秘密來儲存驗證Token：

$ UUID=`uuidgen`
$ echo "$UUID"
$ aws secretsmanager create-secret --name opa_auth_token --secret-string $UUID

執行成功後，傳回的JSON回應包含了秘密的ARN和名稱：

{
  "ARN": "arn:aws:secretsmanager:us-east-2:123456789012:secret:opa_auth_token-07DaVf",
  "Name": "opa_auth_token",
  "VersionId": "f040b1a3-b244-4557-89b5-b6bbf01b1b23"
}

內容解密：

此命令用於在AWS Secrets Manager中建立一個名為opa_auth_token的秘密，用於儲存用於驗證OPA Server的Token。其中：

  • uuidgen命令生成一個唯一的UUID作為Token。
  • aws secretsmanager create-secret命令建立秘密並儲存生成的UUID。

隨著雲端運算和基礎設施即程式碼（IaC）的持續發展，Policy as Code（PaC）和AWS CloudFormation Hook的整合將在以下幾個方面展現出更大的潛力：

  1. 跨雲端平台支援：未來可以考慮將PaC工具擴充套件到其他雲端平台，如Google Cloud Platform（GCP）和Microsoft Azure，實作跨雲端的統一策略管理。
  2. 自動化合規檢查：結合PaC和CI/CDPipeline，實作基礎設施變更的自動化合規檢查，確保每次佈署都符合企業的安全和合規要求。
  3. 智慧化策略最佳化：利用機器學習技術分析歷史資料和現有策略，提供智慧化的策略最佳化建議，進一步提升安全管理效率。

透過不斷創新和改進，PaC與IaC的整合將為企業帶來更高效、更安全、更合規的雲端基礎設施管理方案。

使用OPA和Conftest實作對Terraform的驗證

簡介

隨著Terraform在基礎設施即程式碼（IaC）領域的廣泛應用，如何對Terraform組態檔案進行有效的驗證和管理變得至關重要。本章節將介紹如何使用Open Policy Agent（OPA）和Conftest對Terraform的HCL檔案進行驗證，以確保其符合組織的安全和合規要求。

Terraform與其DSL

Terraform根據HashiCorp Configuration Language（HCL），這是一種人類可讀且機器可解析的組態語言。Terraform作為一種領域特定語言（DSL），在其支援的領域內提供了巨大的價值，尤其是在Policy as Code（PaC）解決方案中。

Terraform DSL的特點

  • 專注與抽象：Terraform透過其DSL特性，專注於基礎設施的定義和管理，減少了不必要的複雜性。
  • 龐大的社群支援：Terraform擁有活躍的社群，提供了大量的提供者（providers）、模組（modules）和第三方整合。
  • 廣泛的應用：Terraform被全球開發者用於多個雲端服務提供商（CSPs）和平台，包括Kubernetes。

使用Conftest和Rego策略驗證Terraform

由於HCL不是JSON或YAML格式，直接使用Rego策略進行驗證存在挑戰。因此，需要將Terraform的HCL檔案轉換為相容的格式，如JSON。

手動解析Terraform計劃為JSON

  1. 初始化Terraform專案：

    $ tf init

    此步驟下載必要的模組和提供者。

  2. 生成Terraform計劃並儲存到檔案：

    $ tf plan --out tfplan

    這一步驟建立了一個二進位制輸出檔案tfplan。

  3. 將Terraform計劃輸出為JSON格式： 為了使用OPA和Conftest，需要將tfplan轉換為JSON格式。

使用OPA伺服器和AWS CFN Hook進行策略執行

在之前的章節中，我們已經介紹瞭如何使用OPA伺服器並透過AWS CFN Hook註冊和組態OPA策略。

組態OPA伺服器

$ opa run -s -l debug --bundle . --authentication=token --authorization=basic

這條命令啟動了一個OPA伺服器，並組態了使用token進行身份驗證。

OPA AuthZ策略示例

package system.authz

default allow := false

allow if {
    input.identity == "661EBD6A-DB07-4CCF-B921-AB5540F668ED"
}

此策略定義了只有特定的UUID token才能被允許存取。

組態AWS CFN Hook指向OPA伺服器

$ aws cloudformation --region "$AWS_REGION" set-type-configuration \
    --configuration "{\"CloudFormationConfiguration\":{\"HookConfiguration\":{\"TargetStacks\":\"ALL\",\"FailureMode\":\"FAIL\",\"Properties\":{\"opaUrl\": \"$OPA_URL\",\"opaAuthTokenSecret\":\"$OPA_AUTH_TOKEN_SECRET\"}}}}" --type-arn $HOOK_TYPE_ARN

這條命令組態了AWS CFN Hook，使其指向OPA伺服器，並使用儲存在AWS Secrets Manager中的token進行身份驗證。

處理程式程式碼片段

headers = {}
secret = type_configuration.opaAuthTokenSecret
if secret is not None and secret != "":
    token = get_secret(type_configuration.opaAuthTokenSecret, session)
    headers = {"Authorization": f"Bearer {token}"}

這段Python程式碼演示瞭如何從AWS Secrets Manager取得token，並將其用於向OPA伺服器發起請求時的身份驗證。

內容擴充與未來方向

未來，可以考慮進一步整合更多的工具和流程，以形成一個完整、自動化的IaC驗證和管理體系。同時，也需要關注相關技術和工具的發展，以便及時調整和最佳化現有的解決方案。

技術挑戰與解決方案

在實施過程中，可能會遇到諸如效能最佳化、策略複雜度管理等技術挑戰。針對這些挑戰，可以採取諸如最佳化Rego策略、使用更高效的資料處理方式等措施來解決。

OPA與Conftest工作流程圖示

  graph LR;
    A[開始] --> B[初始化Terraform];
    B --> C[生成Terraform計劃];
    C --> D[轉換計劃為JSON];
    D --> E[使用Conftest驗證];
    E --> F[根據Rego策略檢查];
    F --> G[輸出驗證結果];
    G --> H[結束];

圖表翻譯： 此圖示展示了使用OPA和Conftest驗證Terraform組態檔案的流程。首先初始化Terraform專案，接著生成Terraform計劃並將其轉換為JSON格式。然後，使用Conftest根據Rego策略對JSON資料進行驗證，最後輸出驗證結果。

詳細程式碼範例與解說

Terraform模組範例

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "18.30.0"

  cluster_name                    = var.cluster_name
  cluster_version                 = var.cluster_version
  cluster_endpoint_private_access = var.cluster_endpoint_private
  cluster_endpoint_public_access  = var.cluster_endpoint_public
  # ... 其他引數 ...
}

內容解密：

此段程式碼使用了Terraform模組來建立Amazon EKS叢集。其中，source指定了模組來源，version指定了使用的模組版本。其他引數如cluster_name、cluster_version等則根據變數進行了設定，用於自定義EKS叢集的組態。

總字數統計：6,023字

本篇文章詳細介紹瞭如何使用OPA和Conftest對Terraform組態檔案進行驗證和管理，涵蓋了從初始化Terraform專案到使用Rego策略進行驗證的整個流程。同時，也探討了相關的技術挑戰和解決方案，並對未來的工作方向進行了展望。透過本文的學習，讀者可以更好地理解如何利用這些工具來提高IaC的安全性和合規性。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。