Kubernetes安全攻防：有效管理的關鍵

– 18 分鐘閱讀

在雲端環境中，單獨處理個別人員或資源通常效率低下。更理想的做法是根據某些特徵來處理人員群組（例如根據角色）或資源群組，如「應用程式X在測試階段的所有Pod和服務」。在發生事件時，能夠識別誰擁有特定資源（如叢集或名稱空間）對於有效處理和升級事件至關重要。

人員分組與團隊政策

各大雲端供應商提供不同的選項來分組人員和定義團隊範圍的政策：

AWS的人員分組方案

AWS Organizations允許以程式化方式建立AWS帳戶並套用政策至群組。它也是其他安全相關服務的基礎，如AWS單一登入(SSO)，通常由AWS Control Tower這類別高階服務進行協調。

# 使用Terraform定義AWS Organizations結構
resource "aws_organizations_organization" "org" {
  feature_set = "ALL"
}

resource "aws_organizations_organizational_unit" "dev" {
  name      = "Development"
  parent_id = aws_organizations_organization.org.roots[0].id
}

resource "aws_organizations_organizational_unit" "prod" {
  name      = "Production"
  parent_id = aws_organizations_organization.org.roots[0].id
}

# 定義服務控制策略(SCP)限制特定操作
resource "aws_organizations_policy" "restrict_regions" {
  name = "RestrictRegions"
  content = jsonencode({
    Version = "2012-10-17",
    Statement = {
      Effect = "Deny",
      Action = "*",
      Resource = "*",
      Condition = {
        StringNotEquals = {
          "aws:RequestedRegion": ["us-east-1", "ap-northeast-1"]
        }
      }
    }
  })
}

此Terraform設定展示瞭如何建立AWS Organizations結構和實施組織範圍的控制。首先建立一個啟用所有功能的組織，然後建立兩個組織單位(OU)：「Development」和「Production」，用於分類別不同環境的帳戶。最後定義了一個服務控制策略(SCP)，限制組織中的帳戶只能使用特定區域(us-east-1和ap-northeast-1)，拒絕所有其他區域的請求。這種方式有效控制了資源使用範圍，提高了安全性和合規性。

Azure的人員分組方案

Azure Policy幫助執行組織標準並評估環境的合規性。此外，Azure根據角色的存取控制(RBAC)用於控制使用者操作。

Google Cloud的人員分組方案

Google的組織政策服務使你能夠定義和執行對組織雲端資源的集中式和程式化控制。Google的IAM允許你宣告誰可以執行操作（許可權），而組織政策則專注於什麼（設定範圍）。

資源分組策略

對於資源分組（從工作節點到整個叢集再到叢集外部資源如負載平衡器或網路儲存），各雲端供應商也提供了不同的控制方式：

AWS的資源分組

AWS提供標籤(Tags)和資源群組(Resource Groups)。標籤已經存在一段時間，有成熟的最佳實踐；而資源群組則是較新的概念。在資源群組引入之前，你基本上必須在每個帳戶基礎上處理扁平的資源名稱空間。當前的良好做法是建立或遵循慣例，並在服務支援的情況下應用它們。

// AWS資源群組標籤策略範例
{
  "TagFilters": [
    {
      "Key": "Environment",
      "Values": ["Production"]
    },
    {
      "Key": "Application",
      "Values": ["WebApp"]
    },
    {
      "Key": "Owner",
      "Values": ["TeamA"]
    }
  ]
}

Azure的資源分組

Azure和AWS都有「資源群組」，但它們並不直接可比。在Azure中，一個資源總是與一個資源群組關聯（可以更改，但不支援根據標籤的多重成員資格）。

Google Cloud的資源分組

GCP在這方面領先：從一開始就支援專案，允許（並強制）你啟用和使用服務、計費、管理協作者以及資源許可權。此外，GCP支援資源標籤，在語義上與Kubernetes中的標籤非常相似。

跨帳戶存取與其他安全考量

多帳戶策略的優勢

使用多個帳戶（如前述結構所強制要求的）有助於自然克服每個帳戶的限制或配額，同時也增強安全態勢。AWS提供了多帳戶策略白皮書作為案例研究。

根據雲端供應商的不同，你可能還有直接應用於資源的政策（而非以人或團隊為中心的政策），這些政策可以幫助跨帳戶存取。

跨帳戶存取實作範例

# 在AWS中設定跨帳戶EKS存取的IAM角色
resource "aws_iam_role" "eks_cross_account" {
  name = "EKSCrossAccountRole"
  
  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Action = "sts:AssumeRole",
        Effect = "Allow",
        Principal = {
          AWS = "arn:aws:iam::${var.trusted_account_id}:root"
        }
      }
    ]
  })
}

# 附加允許EKS存取的政策
resource "aws_iam_role_policy" "eks_access" {
  name = "EKSAccess"
  role = aws_iam_role.eks_cross_account.id
  
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Action = [
          "eks:DescribeCluster",
          "eks:ListClusters"
        ],
        Effect = "Allow",
        Resource = "*"
      }
    ]
  })
}

這段Terraform程式碼建立了一個允許跨帳戶存取EKS的IAM角色。首先定義了一個名為EKSCrossAccountRole的角色，其信任政策允許來自特定帳戶(trusted_account_id變數指定)的主體擔任此角色。接著為該角色附加了一個政策，授予EKS叢集描述和列表許可權。這樣，受信任帳戶中的使用者可以透過擔任此角色來檢視和管理目標帳戶中的EKS資源，實作了安全的跨帳戶存取控制。

根憑證機構的管理

透過TLS進行認證需要PKI憑證，因此問題出現：最好在哪裡儲存根憑證機構(CA)的私鑰和憑證？玄貓建議將根CA儲存在金鑰管理服務(KMS)中，即在允許你管理加密金鑰並以宣告方式定義其使用的受管服務中。這些KMS通常根據硬體安全模組（符合FIPS 140-2），通常還支援稽核，例如在AWS的情況下透過CloudTrail。

避免憑證洩漏

供應鏈的開始是軟體編寫的地方，即開發者或維運人員建立某些成品，如原始碼、YAML格式的設定或Markdown格式的檔案。這些原始成品通常儲存在版本控制系統(VCS)中，如Git，一種流行的分散式VCS，支援協作並使得回退到以前的（良好）狀態成為可能。

然而，VCS也有陰暗面：每當我們將內容放入其中（在分散式VCS中提交和/或推播）時，我們都可能冒著洩漏敏感訊息的風險。

防止憑證洩漏的最佳實踐

有兩件事可以做：

  1. 強制在檢入前進行程式碼掃描：例如，可以使用git-secrets作為預提交鉤子，幫助防止你將敏感訊息提交到Git儲存函式庫。
# 安裝git-secrets
brew install git-secrets  # macOS
# 或使用git clone安裝

# 在儲存函式庫中設定git-secrets
cd your-repository
git secrets --install
git secrets --register-aws  # 註冊AWS憑證模式

# 新增自訂模式
git secrets --add 'private_key'
git secrets --add 'api_key'
  1. 加密敏感訊息：如果需要在（公共）儲存函式庫中儲存敏感訊息，至少不要以純文字形式儲存，而是加密它。例如，Bitnami提供sealed-secrets，允許將過程自動化直到消費目標叢集。
# 使用sealed-secrets加密Kubernetes機密
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: database-credentials
  namespace: default
spec:
  encryptedData:
    username: AgBy8hCM8...truncated...XhaE=
    password: AgAdiPc3x...truncated...fwLs=

上面的YAML展示了使用Bitnami的sealed-secrets工具加密Kubernetes機密。這個工具允許安全地將加密後的敏感資料儲存在版本控制系統中。在這個例子中，資料函式庫的使用者名和密碼被加密成了不可讀的字元串。當這個SealedSecret被應用到Kubernetes叢集時，sealed-secrets控制器會解密這些資料並建立一個標準的Kubernetes Secret資源。這種方法解決了GitOps流程中的一個關鍵問題：如何安全地管理機密資料，同時保持基礎架構即程式碼的完整性。

實用的雲端安全策略

在雲端環境中實施安全策略需要考慮多個層面。玄貓在實際架構設計中發現，結合臨時憑證、精細的資源分組和嚴謹的憑證管理，可以顯著提高雲端環境的安全性。

臨時憑證與自動化

將臨時憑證與CI/CD流程整合是一個強大的安全實踐。例如，在GitLab CI中，可以使用OIDC與AWS STS整合，為每個CI作業提供臨時憑證：

# GitLab CI設定範例，使用OIDC取得AWS臨時憑證
deploy:
  script:
    - >
      export $(aws sts assume-role-with-web-identity
      --role-arn arn:aws:iam::123456789012:role/GitLabCIRole
      --role-session-name GitLabCI
      --web-identity-token $CI_JOB_JWT_V2
      --duration-seconds 900
      --query "Credentials.[AccessKeyId,SecretAccessKey,SessionToken]"
      --output text | sed 's/\t/=/g')
    - aws s3 cp ./build s3://my-app-bucket/ --recursive

多層資源分組策略

有效的資源分組需要多層策略。玄貓建議結合以下方法：

  1. 環境分離：使用獨立帳戶或專案區隔開發、測試和生產環境
  2. 功能分組：根據應用功能或服務型別組織資源
  3. 團隊所有權：清晰定義資源的擁有團隊，便於問題追蹤和解決

安全與效率的平衡

安全措施必須與開發效率取得平衡。玄貓發現，過於嚴格的安全控制可能會導致開發人員尋找捷徑，反而降低整體安全性。理想的做法是：

  • 使安全措施盡可能自動化，減少開發人員的手動操作
  • 提供清晰的安全和工具，使遵循安全最佳實踐變得簡單
  • 定期審查安全措施，確保它們仍然有效與不會不必要地阻礙開發

在雲端環境中執行Kubernetes時，結合雲端提供商的安全服務和Kubernetes原生安全功能，可以建立一個更加堅固的安全架構。臨時憑證的採用、精細的資源分組和嚴謹的憑證管理是構建安全雲端環境的關鍵元素。透過實施這些策略，組織可以顯著降低安全風險，同時維持開發和營運效率。

內部與混合雲環境的安全考量

內部環境與資料中心的定義與區別

在討論企業內部環境時，我們常將「內部環境」(on-premises)與「資料中心」(datacenter)兩詞交替使用。這與裸機佈署(bare-metal deployments)有所區別，後者可能發生在雲端(如AWS、Equinix)或內部環境中。

雲端提供商的環境邊界和其影響通常明確定義，而內部環境則需要自行界定。例如，在AWS中，帳戶是基本的身分單位(一個客戶對應一個帳戶)，大規模時則是AWS Organization代表一個客戶，擁有數十甚至上百個帳戶。同樣地，資源歸屬於特定帳戶，並可為其他帳戶或VPC等更細粒度的結構提供存取許可權。

在內部環境中，玄貓建議你需要自行定義邊界，並應考慮計算單元(是Kubernetes叢集？還是Kubernetes名稱空間？)作為其中一部分。根據業務需求，這可能涉及多租戶要求。

自建Kubernetes叢集的考量

一個關鍵問題是：你是否應該或希望自行執行Kubernetes叢集？這取決於競爭優勢(例如，你是否正在開發自己的Linux發行版?)和你的角色(你是供應商還是終端使用者)。

根據Gartner的資料，雲端採用率仍然只有約20%，而大約50%的Kubernetes使用者仍採用DIY方法。也就是說，他們不使用Red Hat OpenShift、Rancher或Canonical Distribution of Kubernetes等Kubernetes發行版，而是構建和維護自己的發行版。

內部環境基礎設施需求

如果選擇內部佈署，你需要考慮以下基礎設施元件(及其安全影響)：

  1. 硬體基礎：包括建築物、機架、電源供應、發電機、刀片伺服器等，用於執行工作負載。

  2. IaaS虛擬化層：通常是某種IaaS層來虛擬化硬體，如VMware或OpenStack。

  3. 節點級設定：包括使用Ansible或TerraForm等工具進行工作節點級別的設定，提供Kubernetes安裝的基本需求。

  4. 網路設定：

    • 東西向(叢集內)網路流量：透過SDN等滿足Kubernetes需求
    • 南北向網路流量：使用如metalLB或F5等負載平衡器

  5. 儲存解決方案：使用網路儲存如NFS、SAN、物件儲存(MinIO、OpenIO等)、Gluster或Ceph等。

  6. 證書管理：內部證書管理解決方案。

  7. 使用者目錄：通常根據LDAP。

  8. DNS服務：使用Kubernetes內建DNS或現有內部DNS伺服器。

這些是必要的最低需求，與幾乎每個內部環境設定都不相同。這意味著自動化任務的方案(如Ansible指令碼)通常需要大量客製化和測試，才能確保產出有用、可用於生產環境的結果。

內部環境的額外挑戰

除了基本設施外，內部環境還面臨一些特有挑戰，大多數在非全新建置的環境中已經存在：

  1. 實體存取控制：確保基礎設施的實體存取明確定義並執行，這是最具挑戰性的問題之一。

  2. 災難還原計劃：應對地震或火災等最壞情況的能力(災難還原計劃)。

  3. DoS攻擊防護：雲端提供商通常自動與免費處理DoS攻擊，而內部環境需要自行制定策略。

  4. 容量規劃與入侵檢測：在內部環境中，這些工作完全由你負責。

通用安全考量

無論你使用雲端提供商的託管Kubernetes還是執行自己的內部環境，都有一些針對人類(社會工程學)和監管問題的通用考量。

威脅模型爆炸

Kubernetes是一個強大的系統，但這也意味著在理解多重抽象機制和控制迴圈如何被惡意行為者利用時，你必須處理更複雜的情況。

讓我們比較單體應用與Kubernetes環境的攻擊面：

單體應用情境：想像一個在VM上執行的單一二進位檔案。這裡的移動部件很少，職責明確。例如，基礎設施團隊負責VM(修補、升級)，開發人員負責應用程式(依賴掃描、避免SQL注入等)。

Kubernetes環境情境：同樣的應用現在Kubernetes中執行為容器化微服務。這個應用可能與其他15個服務一起處理使用者請求。應用執行在Pod中(Kubernetes抽象)，Pod是同一節點上的容器集合(容器是Linux/OCI抽象)，然後才是執行應用的程式(組)。

此外，工作節點上還執行著kubelet作為本地Kubernetes監督者，使用CRI與容器執行時通訊。還有與Kubernetes控制平面、容器登入檔、CNI外掛等的連線。

Kubernetes引入的複雜性導致了威脅模型爆炸(TME)，主要存在三個問題：

  1. 責任歸屬：端對端安全由誰負責？開發和維運團隊可能需要密切合作以保持所有環境安全。

  2. 抽象帶來的挑戰：抽象使得理解事件發生的原因變得困難，也使測試和監控變得複雜。

  3. 攻擊面擴大：多層抽象提供了比單體應用更大的攻擊面。

應對威脅模型爆炸的最佳實踐

為應對威脅模型爆炸，玄貓建議採用以下良好實踐：

  1. 全方位可見性：測量而非假設。Kubernetes中的每個元件都應該被監控，並設定合理的警示。

  2. 實戰演練：利用停機時間或低流量期進行實操培訓和消防演習。這有助於建立肌肉記憶，使團隊在遭受攻擊時更舒適地升級並採取正確步驟(包含、觀察、捕捉)。

  3. 自動化優先：無論是可觀察性還是升級路徑，所有基本流程都應該自動化，同時為人類提供在必要時手動干預的選項。

這些實踐重點強調了在複雜系統中建立安全文化的重要性。全方位可見性確保所有元件都被監控；實戰演練幫助團隊建立應對危機的能力；而自動化則減少人為錯誤並提高回應速度。這三個方面共同構成了應對Kubernetes環境中威脅模型爆炸的基礎策略。

圖10-2的說明中提到，該圖有意稍微偏頗。在任何實際情況下，單體應用也需要負載平衡器等元件，還有許多其他移動部件。這個比較的重點是：Kubernetes提供了大量資源和API，多到大多數人難以全部記住。它還帶有控制平面和資料平面中的必需和可選(但幾乎總是存在)元件。使用Kubernetes時，即使你只需要或只對一小部分功能感興趣，也無法簡單地選擇結束並忽略所有這些元件，它們仍然存在並為攻擊者提供潛在的攻擊途徑。

因此，在進行威脅建模時，我們需要意識到這些眾多的移動部件，並嘗試考慮盡可能多的因素。

安全實踐的深度思考

從玄貓的經驗來看，Kubernetes環境的安全實踐需要比傳統環境更全面的思考。當我們從單體應用轉向微服務架構時，不僅是技術架構發生了變化，安全思維模式也需要相應調整。

安全責任的變化

在傳統環境中，安全責任界限清晰：基礎設施團隊負責硬體和作業系統安全，開發團隊負責應用程式安全。但在Kubernetes環境中，這種界限變得模糊。例如，Pod安全策略既涉及基礎設施層面的控制，也影回應用程式的執行能力。

這種責任模糊促生了DevSecOps運動，強調安全是開發、維運和安全團隊的共同責任。在實際操作中，這意味著需要建立跨團隊協作機制，共同制定安全標準，並確保從設計階段就考慮安全因素。

可觀測性與安全

在複雜的Kubernetes環境中，可觀測性不僅是維運需求，也是安全需求。完善的日誌記錄、監控和警示系統能夠幫助團隊及時發現異常行為，快速回應安全事件。

玄貓建議建立多層次的監控系統：

  • 基礎設施層監控：關注節點健康、資源使用等
  • Kubernetes元件監控：關注API伺服器、控制器、kubelet等核心元件
  • 應用層監控：關注容器行為、網路流量、資源存取等

這些監控資料應集中收集並建立關聯分析能力，以便在安全事件發生時提供完整的事件鏈。

自動化與安全

自動化是應對Kubernetes複雜性的關鍵。從安全形度看，自動化不僅提高效率，也減少人為錯誤，提升安全性。玄貓推薦以下自動化實踐：

  1. 安全掃描自動化：整合容器映像掃描、程式碼掃描、依賴檢查等到CI/CD流程
  2. 設定驗證自動化：使用工具如OPA Gatekeeper或Kyverno自動驗證資源設定
  3. 安全回應自動化：建立自動化的安全事件回應流程，如異常Pod隔離、日誌收集等

透過這些自動化實踐，團隊可以將更多精力集中在安全策略制定和複雜安全問題解決上，而非重複性的安全檢查任務。

結語

Kubernetes帶來了前所未有的佈署靈活性和擴充套件能力，但同時也帶來了更複雜的安全挑戰。無論是在雲端還是內部環境中佈署Kubernetes，都需要全面考慮基礎設施、網路、儲存、身分驗證等多個層面的安全問題。

威脅模型爆炸是Kubernetes環境面臨的獨特挑戰，需要透過全方位可見性、實戰演練和自動化等實踐來應對。同時，安全不再是單一團隊的責任，而是需要開發、維運和安全團隊共同參與的持續過程。

隨著Kubernetes的普及，安全實踐也在不斷演進。組織需要持續學習和適應新的安全威脅和最佳實踐，建立適合自身環境的安全框架。只有這樣，才能在享受Kubernetes帶來的技術優勢的同時，有效管理其安全風險。

SLO與安全壓力：當可靠性目標成為攻擊媒介

在現代雲原生環境中，服務水準目標(SLO)已成為衡量系統可靠性的重要指標。然而，從安全形度看，這些指標也可能被攻擊者巧妙利用，成為進入系統或竊取資料的管道。

SLO如何被攻擊者武器化

SLO雖然是量化使用者對於系統停機容忍度的絕佳工具，但在安全環境中存在一些隱憂。玄貓在多個安全評估專案中發現，攻擊者通常會從這些角度利用SLO：

服務水準指標(SLI)操縱

攻擊者可能會針對用於測量SLO達成率的服務水準指標(SLI)發動攻擊。透過幹擾或偽造這些測量資料，攻擊者能夠：

# 攻擊者可能使用的SLI幹擾指令碼範例
import requests
import time
import random

# 目標系統的健康檢查端點
health_check_endpoint = "https://target-system.com/health"

# 發動間歇性請求，造成不規則的回應時間波動
while True:
    try:
        # 產生大量請求或特殊請求，使系統回應時間異常
        for _ in range(random.randint(50, 200)):
            requests.get(health_check_endpoint, 
                        headers={"X-Special-Param": "a" * 10000})
        
        # 隨機暫停，製造間歇性問題假象
        time.sleep(random.randint(5, 30))
    except:
        continue

這段程式碼展示了攻擊者如何透過簡單的指令碼來幹擾服務水準指標(SLI)的測量。攻擊者針對系統的健康檢查端點傳送大量請求，並在請求標頭中加入過大的引數值，可能導致系統處理緩慢。關鍵在於其間歇性執行的特性——隨機的請求數量和暫停時間，使得這類別攻擊難以被立即發現。這種攻擊的目的不是完全癱瘓系統，而是製造服務不穩定的假象，進而觸發SLO違規警示，迫使維運團隊在壓力下做出反應。

營造緊急狀態下的判斷失誤

當SLO違規警示響起，團隊通常會進入緊急狀態。在這種高壓環境下：

  1. 團隊成員可能會做出平時不會犯的錯誤
  2. 為了快速還原服務，可能會繞過安全檢查或標準操作流程
  3. 緊急存取許可權可能被授予，而沒有經過正常的審核流程

這就像是對人類的一種分散式拒絕服務攻擊(DDoS)——透過製造壓力環境，誘使人員在判斷和操作上出現失誤。

通知管道的資訊洩露

當SLO違規發生時，警示通常透過各種管道傳送，如簡訊、電子郵件或PagerDuty等服務。如果這些通知系統設定不當，可能會：

  1. 洩露敏感的系統架構資訊
  2. 暴露關鍵服務的依賴關係
  3. 提供攻擊者有價值的團隊結構和聯絡資訊

SLO安全加固建議

在匯入SRE或DevOps實踐時，玄貓建議採取以下措施來保護SLO機制：

  1. 實施SLI測量防護，確保測量機制本身具有抗幹擾能力
  2. 定期審查警示內容，避免在通知中包含敏感資訊
  3. 建立緊急情況下的安全決策流程，即使在高壓環境下也能保持安全意識
  4. 利用新興的OpenSLO等標準化工具，確保SLO定義和測量的一致性與安全性

社交工程：當人成為安全弱點

技術方面的安全措施再完善，如果忽略了人的因素，整個安全體系仍然存在巨大風險。從安全經濟學的角度看，攻擊人員通常比攻擊軟體或硬體更具成本效益。

社交工程的偵察階段

在所有主要攻擊模型中，偵察階段對社交工程攻擊尤為關鍵。攻擊者會收集大量關於目標組織及其員工的資訊，為後續攻擊做準備。

網路攻擊階段模型

雖然目前針對Kubernetes環境的社交工程研究尚不充分，但Wojciech Mazurczyk和Luca Caviglione在2021年3月發表的《網路偵察技術》提供了很好的起點。

社交工程在大型組織中的效果

社交工程在大型與層級分明的組織中尤其有效。當個人感到被剝奪權力，或認為自己只是"機器上的一個齒輪"，加上缺乏所有權意識(“這不是我的錢在風險中”)時，就很容易成為攻擊目標。

常見的社交工程模式與防禦策略

權威訴求攻擊

攻擊模式： 你收到一封來自長官主管的郵件，聲稱由於最近發現的CVE漏洞，你的應用程式需要修補。點選以下連結啟動CD管道中的Helm升級。

防禦策略： 在玄貓參與的安全加固專案中，發現以下策略最為有效：

  1. 標記外部寄件者，例如在主旨行中加入"EXTERNAL"標記
  2. 定期為團隊成員進行培訓和演練
  3. 建立完善的稽核機制，記錄所有關鍵操作

緊急性操縱

攻擊模式： 當壓力大增、時間緊迫時，犯錯的風險會顯著增加。常見的社交工程攻擊會利用某種緊迫感(產品發布、客戶投訴等)來誘騙你分享憑證或對叢集應用變更(“請快速合併這個PR來解決X問題”)。

防禦策略： 在壓力下，反而需要放慢速度。最好的做法是：

  1. 結對工作並大聲說出你的想法和操作步驟
  2. 在應用任何變更前再次檢查和驗證
  3. 建立緊急情況下的快速但安全的決策流程

間接攻擊

攻擊模式： 如同在供應鏈安全中討論的，惡意軟體可能在較不安全的環境中被植入，然後在目標環境中被啟用。

防禦策略： 針對這類別風險，必須：

  1. 主動管理供應鏈安全
  2. 至少對所有進入你環境的專案進行掃描
  3. 將靜態容器映像掃描作為基本防護措施
# 容器映像安全掃描的簡單範例
# 使用Trivy掃描映像並阻止高風險漏洞

#!/bin/bash
IMAGE_NAME=$1
VERSION=$2

# 掃描映像
trivy image --severity HIGH,CRITICAL ${IMAGE_NAME}:${VERSION} > scan_results.txt

# 檢查是否有高危或嚴重漏洞
if grep -q "CRITICAL\|HIGH" scan_results.txt; then
  echo "發現高風險漏洞，拒絕佈署"
  exit 1
else
  echo "安全掃描透過，繼續佈署流程"
  # 繼續佈署流程的命令
fi

這個Bash指令碼展示了一種簡單但有效的容器映像安全把關機制。它使用開放原始碼的Trivy掃描工具來檢測容器映像中的高風險和嚴重漏洞。指令碼接收映像名稱和版本作為引數，然後執行掃描並將結果儲存到檔案中。關鍵部分是使用grep命令檢查結果中是否包含"CRITICAL"或"HIGH"關鍵字，如果發現這些嚴重漏洞，指令碼會中止佈署並回傳錯誤程式碼。這種自動化檢查可以整合到CI/CD管道中，形成供應鏈安全的第一道防線，有效防止被汙染的容器映像進入生產環境。

玄貓

玄貓

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