Helm Chart 安全性深度實踐：簽署驗證與供應鏈防護完整指南

在當今雲端原生的時代，Helm 作為 Kubernetes 生態系中不可或缺的套件管理工具，大幅簡化了應用程式的佈署與管理流程。然而，隨著企業對 Kubernetes 的依賴日益加深，Helm Chart 的安全性議題也變得至關重要。從供應鏈攻擊的角度來看，一個被竄改的 Helm Chart 可能成為入侵整個叢集的關鍵突破口。因此，建立完整的 Helm Chart 安全機制，不僅是技術上的必要措施，更是企業資安治理的重要環節。

數位簽章機制是確保 Helm Chart 來源可靠性與內容完整性的核心防線。透過 GPG（GNU Privacy Guard）的強大加密能力，開發者不僅能驗證下載的 Helm Chart 是否遭到惡意竄改，更能為自己開發的 Chart 加上數位簽章，建立完整的信任鏈。除了簽章機制之外，容器映像的安全性同樣不容忽視。選擇經過安全驗證的基礎映像、定期執行漏洞掃描、設定合理的資源限制，以及貫徹最小權限原則，這些措施共同構成了 Helm Chart 安全佈署的堅實基礎。本文將深入探討這些安全實踐的具體做法，協助您在享受 Helm 便利性的同時，有效降低潛在的安全風險，避免惡意攻擊與資源濫用，讓 Kubernetes 應用程式的管理更加安全可靠。

Helm Chart 數位簽章驗證機制實作

在確保 Helm 套件的安全性方面，數位簽章扮演著不可或缺的角色。當您從官方或第三方儲存庫下載 Helm 執行檔時，通常會發現一個副檔名為 .asc 的檔案，這個檔案包含了對應下載檔案的數位簽章。透過 GPG 工具驗證這個簽章，您可以確認檔案在傳輸過程中是否遭到竄改，並驗證發布者的真實身份。

驗證流程的第一步是執行 gpg --verify 指令來解密並檢查簽章的有效性。這個指令會讀取 .asc 檔案中的簽章資訊，並與下載的檔案內容進行比對。如果簽章驗證成功，代表檔案確實是由持有對應私鑰的發布者所簽署，且內容完整無損。然而，初次驗證時您可能會看到警告訊息，指出公鑰尚未被信任。這是因為 GPG 系統需要使用者明確指定哪些公鑰屬於可信任的對象。

為了消除這個警告，您必須先取得發布者的公鑰指紋，並與官方發布頁面上公布的指紋進行比對。確認指紋一致後，使用 gpg --sign-key 指令簽署該公鑰，表示您信任這個金鑰的合法性。完成這個步驟後，再次執行驗證指令就不會出現警告訊息，整個驗證流程才算完整。

#!/usr/bin/env bash
# 這個腳本示範如何完整驗證 Helm 下載檔案的數位簽章
# 包含金鑰指紋比對與信任建立流程

# 步驟 1：下載 Helm 執行檔與對應的簽章檔
# 這裡以 Helm v3.12.0 為例，實際使用時請替換為最新版本
# -O 參數指定輸出檔名
# -L 參數允許跟隨重新導向

curl -LO https://get.helm.sh/helm-v3.12.0-linux-amd64.tar.gz
curl -LO https://get.helm.sh/helm-v3.12.0-linux-amd64.tar.gz.asc

# 步驟 2：初次驗證簽章
# --verify 參數會檢查簽章的有效性
# 但此時可能出現公鑰未受信任的警告

gpg --verify helm-v3.12.0-linux-amd64.tar.gz.asc helm-v3.12.0-linux-amd64.tar.gz

# 預期輸出會包含以下資訊：
# - 簽章建立時間
# - 使用的 RSA 金鑰 ID
# - 簽署者資訊
# - 公鑰信任狀態警告

# 步驟 3：匯入 Helm 官方公鑰
# 從官方文件取得最新公鑰並匯入
# --recv-keys 參數從金鑰伺服器接收指定金鑰

gpg --recv-keys 967F8AC5E2216F9F4FD270AD92AA783CBAAE8E3B

# 步驟 4：比對金鑰指紋
# --fingerprint 參數顯示金鑰的完整指紋
# 必須與官方網站公布的指紋完全一致

gpg --fingerprint 92AA783CBAAE8E3B

# 步驟 5：簽署並信任該公鑰
# --sign-key 參數表示您信任此金鑰
# 這會使用您的私鑰為官方公鑰加上簽章
# 注意：執行前請務必確認金鑰指紋正確無誤

gpg --sign-key 92AA783CBAAE8E3B

# 步驟 6：再次驗證，此時應不再出現警告
# 成功的驗證會顯示 "Good signature" 且沒有信任警告

gpg --verify helm-v3.12.0-linux-amd64.tar.gz.asc helm-v3.12.0-linux-amd64.tar.gz

# 步驟 7：驗證成功後解壓縮並安裝
# tar 指令解壓縮 tar.gz 檔案
# -z 參數表示使用 gzip 解壓縮
# -x 參數表示解壓縮
# -f 參數指定檔案名稱

tar -zxvf helm-v3.12.0-linux-amd64.tar.gz
sudo mv linux-amd64/helm /usr/local/bin/helm
chmod +x /usr/local/bin/helm

# 步驟 8：清理下載的暫存檔案
# 基於安全考量，安裝完成後應刪除原始檔案與簽章檔

rm -f helm-v3.12.0-linux-amd64.tar.gz*
rm -rf linux-amd64

echo "Helm 安裝完成，數位簽章驗證成功！"

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

actor "開發者" as dev
participant "下載來源" as source
participant "GPG 系統" as gpg
participant "金鑰伺服器" as keyserver
participant "驗證引擎" as verify

dev -> source : 下載 Helm 執行檔與 .asc 簽章檔
source --> dev : 傳回 tarball 與簽章

dev -> gpg : 執行 --verify 指令
gpg -> verify : 讀取簽章檔案內容
verify -> gpg : 回報金鑰未信任警告

dev -> keyserver : 執行 --recv-keys 取得官方公鑰
keyserver --> dev : 傳回公鑰資料

dev -> gpg : 執行 --fingerprint 比對指紋
gpg -> verify : 顯示完整金鑰指紋
dev -> dev : 人工比對官方網站指紋

dev -> gpg : 執行 --sign-key 建立信任
gpg -> gpg : 使用私鑰簽署公鑰

dev -> gpg : 再次執行 --verify 指令
gpg -> verify : 完整驗證簽章有效性
verify --> dev : 回報 "Good signature" 無警告

@enduml

自行簽署 Helm Chart 的完整實作流程

除了驗證官方下載檔案外，為自己開發的 Helm Chart 加上數位簽章，是建立可信賴軟體供應鏈的重要環節。這個過程不僅能讓使用者確認 Chart 的來源真實性，更能確保內容在發布後未被竄改。實作簽署功能前，您需要在工作站上準備好 GPG 金鑰對，若尚未建立，可透過 gpg --generate-key 指令產生新的金鑰組。

簽署 Helm Chart 需要使用 helm package 指令，並搭配幾個關鍵參數。--sign 參數啟用簽署功能，--key 參數指定要用於簽署的金鑰識別碼，而 --keyring 參數則指向包含 PGP 私鑰的金鑰環路徑。執行這個指令後，系統會產生兩個檔案：一個是包含 Helm Chart 的壓縮檔，另一個是 .prov 結尾的 provenance 檔案，內含簽章與後設資料。

provenance 檔案採用 clear ASCII 格式，可以透過文字編輯器檢視其內容。這個檔案記錄了 Chart 的後設資料、壓縮檔的 SHA256 雜湊值，以及使用 PGP 私鑰產生的數位簽章。這些資訊共同構成了完整的責任追溯鏈，讓使用者能夠驗證 Chart 的完整性。為了讓使用者能夠驗證您的簽章，必須將對應的公鑰發布到可公開存取的位置，例如 Keybase 平台或公司內部的金鑰伺服器。

#!/usr/bin/env bash
# 這個腳本示範如何完整簽署 Helm Chart 並發布公鑰
# 包含金鑰格式轉換、簽署流程與 provenance 檔案產生

# 前置準備：檢查 GPG 金鑰是否存在
# --list-keys 參數列出所有可用的公鑰
# 若無金鑰，需先執行 gpg --generate-key 建立

gpg --list-keys

# 步驟 1：轉換金鑰格式（GPG 2.0+ 版本需要）
# Helm 目前需要傳統的 .gpg 格式金鑰環
# --export 參數匯出公鑰，--export-secret-keys 匯出私鑰

gpg --export > ~/.gnupg/pubring.gpg
gpg --export-secret-keys > ~/.gnupg/secring.gpg

# 步驟 2：確認金鑰識別碼
# 金鑰識別碼可以是 Email、姓名或指紋
# 這裡使用 Email 作為範例

export KEY_NAME="[email protected]"

# 步驟 3：封裝並簽署 Helm Chart
# --sign 啟用簽署功能
# --key 指定簽署用的金鑰
# --keyring 指定金鑰環路徑
# ./guestbook 是 Chart 所在的目錄

helm package --sign --key "$KEY_NAME" --keyring ~/.gnupg/secring.gpg ./guestbook

# 執行後會產生兩個檔案：
# - guestbook-1.0.0.tgz : 包含 Chart 內容的壓縮檔
# - guestbook-1.0.0.tgz.prov : provenance 檔案，包含簽章與後設資料

# 步驟 4：檢視 provenance 檔案內容
# provenance 檔案採用 ASCII 明文格式，可用 cat 指令檢視

cat guestbook-1.0.0.tgz.prov

# 檔案內容包含：
# - Chart.yaml 的完整後設資料
# - Chart 壓縮檔的 SHA256 雜湊值
# - PGP 數位簽章

# 步驟 5：匯出公鑰供使用者驗證
# --armor 參數產生 ASCII 格式的公鑰，方便分享
# --export 參數匯出指定金鑰的公開部分

gpg --armor --export "$KEY_NAME" > pubkey.asc

# 步驟 6：發布公鑰到可信平台
# 建議發布到 Keybase 或公司內部金鑰伺服器
# 這裡示範如何使用 Keybase

keybase pgp push --email "$KEY_NAME"

# 步驟 7：建立完整的發布套件
# 包含 Chart 壓縮檔、provenance 檔案與公鑰

mkdir helm-release-v1.0.0
mv guestbook-1.0.0.tgz* helm-release-v1.0.0/
mv pubkey.asc helm-release-v1.0.0/
cd helm-release-v1.0.0

# 步驟 8：產生完整性驗證檔案
# 為整個發布套件產生 SHA256 總和檢查碼

sha256sum * > SHA256SUMS

# 步驟 9：簽署完整性驗證檔案
# 確保總和檔案本身未被竄改

gpg --local-user "$KEY_NAME" --detach-sign SHA256SUMS

echo "Helm Chart 簽署完成！"
echo "請將 helm-release-v1.0.0/ 目錄內容上傳至發布位置"

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

actor "Chart 開發者" as dev
participant "GPG 系統" as gpg
participant "Helm CLI" as helm
participant "檔案系統" as fs

dev -> gpg : 執行 --export 轉換金鑰格式
gpg -> fs : 寫入 ~/.gnupg/pubring.gpg
gpg -> fs : 寫入 ~/.gnupg/secring.gpg

dev -> helm : 執行 helm package --sign
helm -> gpg : 請求使用私鑰簽署
gpg -> helm : 回傳數位簽章

helm -> fs : 產生 Chart 壓縮檔 (.tgz)
helm -> fs : 產生 provenance 檔案 (.tgz.prov)

dev -> gpg : 執行 --armor --export
gpg -> fs : 產生 pubkey.asc 公鑰檔

dev -> fs : 建立發布套件目錄
dev -> fs : 產生 SHA256SUMS 檢查檔
dev -> gpg : 簽署檢查檔

@enduml

Helm Chart 驗證與安裝的安全流程

當使用者取得已簽署的 Helm Chart 後，驗證程序是確保安全佈署的關鍵步驟。helm verify 指令專門用於驗證 Chart 的完整性與簽章有效性。執行這個指令時，系統會同時讀取 .tgz 壓縮檔與 .tgz.prov provenance 檔案，進行多層次的驗證檢查。

驗證過程首先會確認 provenance 檔案的格式正確性，接著比對壓縮檔的實際 SHA256 雜湊值與 provenance 檔案中記錄的預期值是否一致。這個步驟確保了 Chart 內容自簽署後未被任何方式竄改。隨後，系統會使用發布者的公鑰來驗證 provenance 檔案中的 PGP 簽章是否有效。如果所有檢查都通過，helm verify 指令將不會產生任何輸出，表示驗證成功；若有任何一項檢查失敗，則會顯示詳細的錯誤訊息，說明驗證失敗的原因。

為了簡化使用者的操作，Helm 提供了 --verify 參數，可以在安裝 Chart 的同時執行驗證。這個參數會在安裝前自動呼叫驗證引擎，確保只有通過驗證的 Chart 才會被佈署到 Kubernetes 叢集中。這種驗證與安裝一體化的做法，大大提升了安全佈署的便利性。

#!/usr/bin/env bash
# 這個腳本示範如何完整驗證並安裝已簽署的 Helm Chart
# 包含公鑰匯入、簽章驗證與安全安裝流程

# 步驟 1：從可信來源下載 Chart 與 provenance 檔案
# 這裡假設檔案已從官方儲存庫或內部 Artifactory 下載
# -O 參數保留原始檔名

curl -LO https://charts.example.com/guestbook-1.0.0.tgz
curl -LO https://charts.example.com/guestbook-1.0.0.tgz.prov

# 步驟 2：從可信平台下載發布者公鑰
# 這裡從 Keybase 下載，實際使用時也可以是內部金鑰伺服器

curl -LO https://keybase.io/exampledeveloper/pgp_keys.asc

# 步驟 3：匯入公鑰至 GPG 金鑰環
# --import 參數將公鑰加入本地資料庫

gpg --import pgp_keys.asc

# 步驟 4：驗證公鑰指紋（關鍵安全步驟）
# 必須與發布者在官方管道公布的指紋完全一致

gpg --fingerprint [email protected]

# 步驟 5：執行 Helm 驗證指令
# --keyring 參數指定包含公鑰的金鑰環
# 驗證成功時不會有任何輸出

helm verify --keyring ~/.gnupg/pubring.gpg guestbook-1.0.0.tgz

# 步驟 6：檢查驗證回傳碼
# 若驗證失敗，$? 變數會包含非零值

if [ $? -eq 0 ]; then
    echo "簽章驗證成功！Chart 完整性確認無誤。"
else
    echo "簽章驗證失敗！請勿安裝此 Chart。"
    exit 1
fi

# 步驟 7：安全安裝 Chart
# --verify 參數確保安裝前自動執行驗證
# --keyring 指定驗證用的金鑰環

helm install my-guestbook guestbook-1.0.0.tgz \
  --verify \
  --keyring ~/.gnupg/pubring.gpg \
  --namespace production \
  --create-namespace

# 步驟 8：檢查安裝結果

helm list -n production

# 步驟 9：清理下載的檔案
# 基於安全考量，安裝完成後應刪除敏感檔案

shred -u guestbook-1.0.0.tgz*
shred -u pgp_keys.asc

echo "Helm Chart 安裝完成！"

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

actor "佈署人員" as deployer
participant "下載來源" as source
participant "金鑰平台" as keybase
participant "GPG 系統" as gpg
participant "Helm CLI" as helm
participant "Kubernetes 叢集" as k8s

deployer -> source : 下載 .tgz 與 .tgz.prov
source --> deployer : 傳回 Chart 與 provenance

deployer -> keybase : 下載發布者公鑰
keybase --> deployer : 傳回 pgp_keys.asc

deployer -> gpg : 執行 --import 匯入公鑰
gpg -> gpg : 驗證金鑰格式
gpg -> deployer : 回報匯入結果

deployer -> helm : 執行 helm verify
helm -> gpg : 請求驗證簽章
gpg -> gpg : 比對 SHA256 雜湊值
gpg -> gpg : 驗證 PGP 簽章有效性
gpg --> helm : 回傳驗證結果

alt 驗證成功
    helm -> k8s : 執行安裝佈署
    k8s --> helm : 回報安裝狀態
    helm --> deployer : 顯示安裝成功訊息
else 驗證失敗
    helm --> deployer : 顯示錯誤並終止安裝
end

@enduml

Helm Chart 進階安全實踐

在 Helm Chart 的安全實踐中，容器映像的管理是極為關鍵的環節。由於 Kubernetes 和 Helm 的核心功能是佈署與管理容器化應用程式，因此映像本身的安全性直接影響整個叢集的安全狀態。開發者必須深入理解映像標籤（Tag）與映像摘要（Digest）之間的本質差異，並在實務中正確使用。

映像標籤雖然提供了人類可讀的參考方式，方便開發者識別與管理不同版本的映像，但標籤本身是可變動的。這意味著同一個標籤在不同時間可能指向完全不同的映像內容，這種不確定性為安全性帶來了潛在風險。攻擊者可能利用這個特性，將惡意映像推送至與現有標籤相同的名稱，導致後續佈署在不知不覺中使用到被污染的映像。

相對地，映像摘要是透過 SHA-256 演算法計算得出的唯一識別碼，具有不可變更的特性。每個映像內容都會產生獨一無二的摘要值，任何微小的變更都會導致摘要完全不同。這種特性讓容器執行時期能夠精確驗證映像內容，確保佈署的映像與預期完全一致。因此，在 Helm Chart 中參考容器映像時，強烈建議使用完整的摘要值而非標籤，這是防止供應鏈攻擊的有效防護措施。

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

left to right direction

node "Helm Chart 設定" as chart {
  [Chart.yaml] as metadata
  [values.yaml] as values
  [templates/] as templates
}

node "容器映像參考方式" as ref {
  [使用 Image Tag] as tag
  [使用 Image Digest] as digest
}

node "安全性比較" as security {
  [可能遭竄改] as risk
  [不可變更安全] as safe
}

chart -> templates : 定義映像參考
templates -> tag : 使用 redis:5.0.9
templates -> digest : 使用 redis@sha256:70b816f...

tag -> risk : Tag 可被重新指向
tag -> risk : 供應鏈攻擊風險

digest -> safe : Digest 唯一對應
digest -> safe : 內容驗證機制

note right of chart
  Helm Chart 中的映像參考
  直接影響佈署安全性
end note

note bottom of security
  建議：永遠使用 Image Digest
  確保映像內容不可變更
end note

@enduml

容器漏洞掃描與映像更新策略

隨著時間推移，任何使用特定標籤或摘要的容器映像都可能因為新發現的安全漏洞而變得不安全。這些漏洞可能存在於映像包含的作業系統套件、應用程式相依函式庫，或是基礎映像本身的系統程式中。因此，建立定期的漏洞掃描機制與映像更新策略，是維護 Helm Chart 長期安全性的必要工作。

目前業界提供多種容器漏洞掃描方案。許多容器映像註冊中心，如 Quay、Nexus Repository 和 JFrog Artifactory，都內建了自動化掃描功能。這些工具能夠定期檢查註冊中心中儲存的映像，比對最新的 CVE 漏洞資料庫，並產生詳細的安全報告，指出映像中包含的已知漏洞數量與嚴重等級。除了註冊中心的原生功能外，也有獨立的開源掃描工具可供選擇，例如 Clair、Anchore Engine、Vuls 和 OpenSCAP，這些工具能夠整合至 CI/CD 管道中，在映像建構階段即進行安全檢查。

當掃描報告指出某個容器映像存在漏洞時，開發團隊應立即評估風險等級並制定修復計畫。輕微漏洞可能只需在下次定期更新時處理，但高風險或重大漏洞則需要緊急應變，立即更新 Helm Chart 中使用的映像版本，防止漏洞被引入正式環境的 Kubernetes 叢集中。這種主動式的安全管理，能夠大幅降低供應鏈攻擊的成功機率。

#!/usr/bin/env bash
# 這個腳本示範如何在 CI/CD 管道中整合容器漏洞掃描
# 使用 Trivy 作為掃描工具，並根據掃描結果決定是否通過建構

# 設定錯誤處理，任何錯誤都會立即終止腳本
set -euo pipefail

# 定義掃描參數
# HIGH,CRITICAL 表示只關注高風險與重大漏洞
# --exit-code 1 表示發現漏洞時回傳非零值
# --no-progress 減少輸出訊息

SCAN_PARAMS="--severity HIGH,CRITICAL --exit-code 1 --no-progress"

# 步驟 1：掃描基礎映像
# 這裡掃描 Helm Chart 中使用的 Redis 映像
# 目的是在佈署前發現基礎映像的漏洞

echo "開始掃描基礎映像：redis:5.0.9"

if trivy image $SCAN_PARAMS redis:5.0.9; then
    echo "基礎映像掃描通過，未發現高風險漏洞。"
else
    echo "基礎映像掃描失敗，發現重大安全漏洞！"
    echo "請立即更新至安全版本或切換替代映像。"
    exit 1
fi

# 步驟 2：建構應用程式映像
# 這裡假設 Dockerfile 位於當前目錄
# -t 參數指定映像標籤，使用 Git commit SHA 確保唯一性

docker build -t myapp:${GIT_COMMIT_SHA} .

# 步驟 3：掃描自建映像
# 掃描剛建構完成的應用程式映像
# 確保應用層也沒有引入新漏洞

echo "開始掃描應用程式映像：myapp:${GIT_COMMIT_SHA}"

if trivy image $SCAN_PARAMS myapp:${GIT_COMMIT_SHA}; then
    echo "應用程式映像掃描通過。"
else
    echo "應用程式映像掃描失敗！"
    echo "請檢查應用程式相依套件是否存在已知漏洞。"
    exit 1
fi

# 步驟 4：產生映像安全報告
# --format json 產生結構化報告供後續分析
# --output 將報告儲存至檔案

trivy image --severity HIGH,CRITICAL --format json \
    --output security-report.json myapp:${GIT_COMMIT_SHA}

# 步驟 5：上傳安全報告至儲存系統
# 這裡示範上傳至 S3，實際可整合至內部文件系統

aws s3 cp security-report.json s3://security-reports/myapp/${GIT_COMMIT_SHA}/

# 步驟 6：在 Helm values 中使用安全映像摘要
# 取得映像的 SHA256 摘要值
# --no-trunc 確保取得完整摘要

IMAGE_DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' myapp:${GIT_COMMIT_SHA})

# 更新 Helm values.yaml 檔案
# 使用 sed 指令將映像參考從 tag 改為 digest

sed -i "s|repository: myapp|repository: myapp@${IMAGE_DIGEST}|g" values.yaml
sed -i "/tag:/d" values.yaml

echo "映像安全掃描完成，已更新 values.yaml 使用映像摘要！"

# 步驟 7：清理本地映像（基於安全考量）
# 避免在 CI 環境留下可能含漏洞的映像

docker rmi myapp:${GIT_COMMIT_SHA} redis:5.0.9

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

participant "CI/CD 平台" as cicd
participant "映像註冊中心" as registry
participant "Trivy 掃描器" as trivy
participant "安全報告儲存" as storage
participant "Helm CLI" as helm

cicd -> registry : 拉取基礎映像
cicd -> trivy : 執行基礎映像掃描
trivy -> registry : 分析映像層
trivy -> trivy : 比對 CVE 資料庫

alt 發現重大漏洞
    trivy --> cicd : 回傳失敗碼
    cicd -> cicd : 終止建構流程
    cicd -> cicd : 發送安全警報
else 掃描通過
    trivy --> cicd : 回傳成功碼
    
    cicd -> cicd : 建構應用程式映像
    
    cicd -> trivy : 執行應用程式映像掃描
    trivy -> registry : 分析應用層
    trivy -> trivy : 檢測應用漏洞
    
    alt 發現漏洞
        trivy --> cicd : 回傳失敗碼
        cicd -> cicd : 封鎖映像推播
    else 掃描通過
        trivy -> storage : 上傳詳細報告
        
        cicd -> registry : 推送安全映像
        
        cicd -> helm : 更新 Chart 使用映像摘要
        helm -> cicd : 產生最終部署套件
        
        cicd -> cicd : 觸發部署至 Kubernetes
    end
end

@enduml

資源限制與最小權限原則實作

在 Kubernetes 叢集中，Pod 會直接使用底層節點的運算資源。若未設定適當的資源限制，單一 Pod 可能耗盡節點的 CPU 或記憶體資源，導致節點上的其他工作負載受到影響，甚至可能引發整個節點的不穩定。這種資源競爭問題在多用戶共享的叢集環境中尤其嚴重。因此，玄貓強烈建議 Helm Chart 開發者必須在 Chart 中設定合理的資源限制，或是在叢集層級透過 LimitRange 與 ResourceQuota 強制實施資源管制。

多數 Helm Chart 允許在 values.yaml 檔案中宣告 resources 欄位，開發者應該預設設定這個欄位，確保應用程式至少有最基本的資源保障。這不僅能防止 Pod 過度消耗節點資源，更能為應用程式的資源需求提供明確的參考基準。以下是一個在 values.yaml 中設定資源限制的範例，這個設定會將 Pod 的 CPU 使用上限限制在 500 毫核心（500m），記憶體使用上限限制在 2GiB。

除了資源限制外，容器執行的權限也是安全考量的重點。應盡量避免以 root 使用者身份執行容器，因為這會賦予容器所有 Linux 權能（Capabilities），大幅增加安全風險。權能是 Linux 核心提供的機制，允許程式擁有部分 root 權限，例如 NET_ADMIN 可執行網路相關操作、SYS_TIME 可修改系統時間等。開發者應該明確列出並僅授予容器執行所必需的權能，任何非必要的權能都應該移除。這種最小權限原則能有效降低攻擊面，即使容器遭到入侵，也能最大限度地減少對整個叢集造成的潛在傷害。

# 這個 YAML 檔案展示如何在 Helm Chart 中設定安全參數
# 包含資源限制、安全性上下文與權限控制

# values.yaml 中的資源限制設定
# 這些設定會被 templates/deployment.yaml 引用

resources:
  # limits 定義資源使用上限
  # 防止 Pod 耗盡節點資源
  limits:
    # CPU 限制為 500 毫核心（0.5 核心）
    # 1000m 等於 1 個 CPU 核心
    cpu: "500m"
    # 記憶體限制為 2GiB
    # 超過此限制會觸發 OOM Killer
    memory: "2Gi"
  # requests 定義資源需求
  # 用於 Kubernetes 排程決策
  requests:
    # 保證分配 100 毫核心 CPU
    cpu: "100m"
    # 保證分配 256MiB 記憶體
    memory: "256Mi"

# Pod 層級的安全性設定
podSecurityContext:
  # 以非 root 使用者執行
  # runAsNonRoot: true 強制要求容器必須以非 root 身份執行
  runAsNonRoot: true
  # 指定執行使用者 ID
  # 範圍通常建議使用 1000-65535 之間的數值
  runAsUser: 1000
  # 指定執行群組 ID
  runAsGroup: 1000
  # 設定檔案系統群組 ID
  # 用於 Volume 掛載時的權限設定
  fsGroup: 1000

# 容器層級的安全性設定
securityContext:
  # 停用特權模式
  # 特權容器擁有主機的所有權限，應該避免使用
  privileged: false
  # 限制可用的 Linux 權限
  # 只授予必要的最小權限集合
  capabilities:
    # drop 表示移除所有預設權限
    drop:
      - ALL
    # add 表示僅添加特定需要的權限
    # 這裡只加入 NET_BIND_SERVICE，允許綁定低端口
    add:
      - NET_BIND_SERVICE
  # 設定唯讀根檔案系統
  # 防止容器內部檔案被修改
  readOnlyRootFilesystem: true
  # 停用權限升級
  # 防止程式在容器內取得更高權限
  allowPrivilegeEscalation: false

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

node "Kubernetes 節點" as node {
  [節點資源] as resources
  
  node "Pod" as pod {
    [容器應用程式] as app
    [安全性上下文] as security
  }
  
  [資源限制設定] as limits
}

resources --> limits : 由 LimitRange 限制
limits --> pod : 套用資源上限
limits --> pod : 套用資源需求

pod -> app : 以非 root 使用者執行
pod -> app : 唯讀檔案系統
pod -> app : 限制 Linux 權限

security --> app : 停用權限升級
security --> app : 停用特權模式

note right of node
  資源限制與安全設定
  共同確保節點穩定與叢集安全
end note

note bottom of pod
  最小權限原則實作：
  - 僅授予必要資源
  - 僅授予必要權限
  - 限制檔案系統寫入
end note

@enduml

企業級 CI/CD 整合安全流程

將 Helm Chart 的安全性實踐整合至企業的 CI/CD 管道中，是確保持續安全佈署的關鍵。完整的整合流程應該在管道的每個階段都設置安全檢查點，從原始碼提交到正式環境佈署，形成多層次的防護網。這種自動化的安全檢查不僅能減少人為疏失，更能確保每個 Helm Chart 在發布前都經過嚴格的安全驗證。

理想的整合流程應包含以下關鍵階段：當開發者提交程式碼時，觸發靜態程式碼分析與安全掃描，檢查 Chart 中是否存在硬編碼密碼或不安全的預設值。在建構階段，為 Chart 產生數位簽章並建立完整的 provenance 檔案。接著執行單元測試與整合測試，驗證 Chart 在各種情境下的行為是否符合預期。最後，在佈署至正式環境前，必須經過人工核准閘門，由資安團隊審核所有安全掃描報告與測試結果。

這種分層驗證的機制確保了每個 Helm Chart 都經過充分的安全檢查，同時也為企業提供了完整的稽核軌跡。所有驗證結果與簽章資訊都應該被妥善記錄與保存，以便未來進行資安事件調查或法規遵循查核時，能夠追溯每個 Chart 的完整生命周期。

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

actor "開發者" as dev
participant "Git 儲存庫" as git
participant "CI/CD 平台" as cicd
participant "安全掃描服務" as scanner
participant "GPG 簽署服務" as signer
participant "Helm 儲存庫" as helmrepo
participant "Kubernetes 叢集" as k8s

dev -> git : 推送 Helm Chart 程式碼
git -> cicd : 觸發建構管道

cicd -> cicd : 執行靜態程式碼分析
cicd -> scanner : 掃描 Chart 安全性
scanner -> scanner : 檢查硬編碼密碼
scanner -> scanner : 驗證資源限制設定
scanner --> cicd : 回傳掃描報告

alt 掃描發現重大問題
    cicd -> dev : 通知修正安全問題
    cicd -> cicd : 終止建構流程
else 掃描通過
    cicd -> signer : 請求數位簽章
    signer -> signer : 使用私鑰簽署 Chart
    signer --> cicd : 回傳 .tgz 與 .tgz.prov
    
    cicd -> cicd : 執行單元測試
    cicd -> cicd : 執行整合測試
    
    alt 測試失敗
        cicd -> dev : 通知測試失敗
    else 測試成功
        cicd -> helmrepo : 發布簽署後的 Chart
        helmrepo --> cicd : 確認發布成功
        
        cicd -> cicd : 產生安全性報告
        
        cicd -> dev : 通知等待人工核准
        
        dev -> cicd : 核准正式環境佈署
        
        cicd -> k8s : 執行 helm install --verify
        k8s -> k8s : 驗證簽章有效性
        k8s -> k8s : 佈署應用程式
        
        cicd -> cicd : 記錄完整稽核軌跡
    end
end

@enduml

結論與企業導入建議

在台灣的企業環境中導入 Helm Chart 安全機制時，必須考量本地的資安法規與產業特性。金融業因受到金管會的嚴格監管，對於容器安全與供應鏈完整性有極高的要求，必須確保每個 Helm Chart 都有完整的簽章與驗證流程。高科技製造業則需面對複雜的供應鏈資安挑戰，必須防止惡意程式碼透過 Helm Chart 滲透至生產環境。

建議企業採取漸進式的導入策略。初期可先從內部使用的 Helm Chart 開始實施簽署機制，建立團隊對 GPG 與 Helm 簽章流程的熟悉度。接著，將漏洞掃描整合至現有的 CI/CD 管道中，對所有使用的容器映像執行安全檢查。第三階段則可建立企業級的 Helm 儲存庫，強制要求所有 Chart 必須經過簽署與驗證才能發布。

同時，應建立跨部門的安全工作小組，納入開發、維運、資安與法務等相關單位，共同制定符合企業實際需求的 Helm Chart 安全政策。透過這種協作模式，才能確保技術方案不僅能提升安全性，更能符合企業的營運需求與法規遵循義務。

最終，成功的 Helm Chart 安全管理不僅依賴於先進的工具與技術，更需要建立完整的治理框架、培養團隊的安全意識，並持續監控與改善相關流程。唯有將技術、流程與人員三個層面緊密結合，才能在當前複雜的威脅環境中，有效保護企業的 Kubernetes 應用程式資產，確保軟體供應鏈的完整性與可信度。