Kubernetes Helm 安全佈署實踐：資源限制、Secrets 管理與 RBAC 策略

# 這個 YAML 檔案示範如何建立 LimitRange 來限制單一 PVC 的儲存空間
# LimitRange 會強制執行資源使用的絕對最大值
# 使用者可以在 values.yaml 中設定預設值，但不得超過此限制

apiVersion: v1
kind: LimitRange
metadata:
  # LimitRange 物件的名稱，建議使用具有描述性的名稱
  name: limits-per-pvc
  # 指定此 LimitRange 作用的命名空間
  # 建議為每個專案或團隊建立獨立的命名空間
  namespace: production-apps
spec:
  # 定義限制的規則清單，可包含多個項目
  limits:
    # 對 PersistentVolumeClaim 類型資源的限制
    - type: PersistentVolumeClaim
      # max 定義資源可申請的最大值
      # 這裡限制單一 PVC 最多只能申請 4Gi 儲存空間
      max:
        storage: 4Gi
      # min 定義資源可申請的最小值
      # 可以防止過度保守的資源申請
      min:
        storage: 1Gi
      # defaultRequest 定義未明確指定時的預設申請值
      defaultRequest:
        storage: 2Gi
      # default 定義未明確指定時的預設限制值
      default:
        storage: 2Gi

# 這個 YAML 檔案示範如何建立 ResourceQuota 來限制整個命名空間的資源使用總量
# ResourceQuota 從命名空間層級防止資源過度消耗

apiVersion: v1
kind: ResourceQuota
metadata:
  # ResourceQuota 物件的名稱
  name: pod-and-pvc-quota
  # 指定此 ResourceQuota 作用的命名空間
  namespace: production-apps
spec:
  # hard 定義資源使用的硬性上限，不可超過
  hard:
    # 限制整個命名空間的 CPU 使用總量為 4 核心
    # 這是所有 Pod 的 limits.cpu 總和上限
    limits.cpu: "4"
    # 限制整個命名空間的記憶體使用總量為 8GiB
    # 這是所有 Pod 的 limits.memory 總和上限
    limits.memory: 8Gi
    # 限制整個命名空間的儲存申請總量為 20GiB
    # 這是所有 PVC 的 requests.storage 總和上限
    requests.storage: 20Gi
    # 限制 Secrets 的總數量為 10 個
    # 防止過多 Secrets 造成管理困難
    secrets: "10"
    # 限制 ConfigMaps 的總數量為 10 個
    configmaps: "10"
    # 限制 PersistentVolumeClaims 的總數量為 5 個
    persistentvolumeclaims: "5"

# 這個 YAML 檔案示範如何在 Helm Chart 中安全地處理敏感資訊
# 使用 required 函式強制使用者提供密碼，避免使用不安全的預設值

apiVersion: v1
kind: Secret
metadata:
  # Secret 物件的名稱，建議包含應用程式名稱以便識別
  name: {{ .Release.Name }}-database-credentials
  # Secret 所在的命名空間
  namespace: {{ .Release.Namespace }}
type: Opaque
data:
  # 使用 required 函式確保使用者必須提供密碼
  # 若未提供，安裝流程會立即終止並顯示錯誤訊息
  # b64enc 函式將字串轉換為 Base64 編碼，符合 Kubernetes Secret 格式要求
  password: {{ required "資料庫密碼為必填項目，請使用 --set db.password=YOUR_PASSWORD 提供" .Values.db.password | b64enc }}
  # 使用者名稱同樣建議由使用者提供，而非使用預設值
  username: {{ required "資料庫使用者名稱為必填項目" .Values.db.username | b64enc }}

# 這個 YAML 檔案示範如何從外部密碼管理服務動態取得敏感值
# 使用 Helm 的 lookup 函式在安裝時查詢已存在的 Secret

{{- if .Values.externalSecrets.enabled }}
apiVersion: v1
kind: Secret
metadata:
  name: {{ .Release.Name }}-external-api-key
  namespace: {{ .Release.Namespace }}
type: Opaque
data:
  # 使用 lookup 函式查詢外部 Secret 管理服務中的值
  # 這個範例查詢 HashiCorp Vault 注入的 Secret
  # 若找不到對應值，使用 required 函式強制提供
  api-key: {{ required "API Key is required when externalSecrets is enabled" (index (lookup "v1" "Secret" "vault-secrets" "external-api-credentials").data "api-key") | default "" | b64enc }}
{{- end }}

# 這個 YAML 檔案示範如何建立自訂的 RBAC 角色
# 此角色僅授予查詢 Pod 的權限，遵循最小權限原則

apiVersion: rbac.authorization.k8s.io/v1
# 使用 Role 而非 ClusterRole，限制在特定命名空間內
kind: Role
metadata:
  # 角色名稱應該具備描述性，表明其用途
  name: guestbook-pod-viewer
  # 角色作用的命名空間
  namespace: production-apps
# rules 定義角色擁有的權限規則
rules:
  # apiGroups 指定 Kubernetes API 群組
  # 空字串表示核心 API 群組
  - apiGroups: [""]
    # resources 指定可存取的資源類型
    resources: ["pods"]
    # verbs 指定允許執行的操作
    # 這裡只授予讀取相關操作
    verbs: ["get", "watch", "list"]

# 這個 YAML 檔案示範如何建立 ServiceAccount
# ServiceAccount 是 Pod 使用的身份認證機制

apiVersion: v1
kind: ServiceAccount
metadata:
  # ServiceAccount 名稱，與角色名稱保持一致性
  name: guestbook
  # ServiceAccount 所在的命名空間
  namespace: production-apps
# automountServiceAccountToken 控制是否自動掛載憑證
# 設為 false 可提升安全性，手動控制憑證掛載
automountServiceAccountToken: false

# 這個 YAML 檔案示範如何建立 RoleBinding
# 將角色與 ServiceAccount 綁定，授予實際權限

apiVersion: rbac.authorization.k8s.io/v1
# 使用 RoleBinding 將命名空間內的角色綁定
kind: RoleBinding
metadata:
  # 綁定名稱，建議包含角色與主體資訊
  name: guestbook-pod-viewers
  # 綁定所在的命名空間，需與角色相同
  namespace: production-apps
# subjects 定義要授予權限的對象
subjects:
  # kind 指定主體類型
  - kind: ServiceAccount
    # name 指定 ServiceAccount 名稱
    name: guestbook
    # namespace 指定 ServiceAccount 所在命名空間
    namespace: production-apps
# roleRef 定義要綁定的角色
roleRef:
  # kind 指定角色類型
  kind: Role
  # name 指定角色名稱
  name: guestbook-pod-viewer
  # apiGroup 指定角色的 API 群組
  apiGroup: rbac.authorization.k8s.io

#!/usr/bin/env bash
# 這個腳本提供完整的 RBAC 設定驗證流程
# 從環境準備到權限驗證，確保安全設定正確運作

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

# 定義顏色輸出函數，用於顯示不同等級的訊息
# 這些顏色定義符合多數終端機的 ANSI 色彩碼
GREEN='\033[0;32m'
RED='\033[0;31m'
NC='\033[0m' # No Color

# 步驟 1：準備測試環境
# 建立獨立的命名空間，避免影響現有應用程式
# chapter9 作為測試用途的命名空間名稱

echo "步驟 1：建立測試命名空間 chapter9..."
kubectl create ns chapter9

# 步驟 2：建立自訂 RBAC 角色
# 建立名為 guestbook-pod-viewer 的角色
# 僅授予查詢 Pod 的權限，遵循最小權限原則
# --resource=pods 指定可操作資源
# --verb=get,list 指定允許的操作：取得與列出

echo "步驟 2：建立自訂角色 guestbook-pod-viewer..."
kubectl create role guestbook-pod-viewer \
  --resource=pods \
  --verb=get,list \
  -n chapter9

# 步驟 3：建立 ServiceAccount
# ServiceAccount 是 Pod 使用的身份認證機制
# guestbook 服務帳戶將被綁定到自訂角色

echo "步驟 3：建立 ServiceAccount guestbook..."
kubectl create sa guestbook -n chapter9

# 步驟 4：建立 RoleBinding
# 將角色與服務帳戶綁定，授予實際權限
# --role 指定要綁定的角色名稱
# --serviceaccount 指定目標服務帳戶，格式為 namespace:serviceaccount

echo "步驟 4：建立 RoleBinding guestbook-pod-viewers..."
kubectl create rolebinding guestbook-pod-viewers \
  --role=guestbook-pod-viewer \
  --serviceaccount=chapter9:guestbook \
  -n chapter9

# 步驟 5：驗證權限設定
# 使用 kubectl auth can-i 檢查服務帳戶權限
# --as 標誌模擬特定身份進行授權檢查
# 這個測試驗證 serviceaccount 是否可以列出 Pod

echo "步驟 5：驗證 ServiceAccount 權限..."
if kubectl auth can-i list pods \
  --as=system:serviceaccount:chapter9:guestbook \
  -n chapter9; then
  echo -e "${GREEN}✓ ServiceAccount 具有 list pods 權限${NC}"
else
  echo -e "${RED}✗ 權限驗證失敗${NC}"
  exit 1
fi

# 步驟 6：測試拒絕未授權操作
# 確認服務帳戶無法執行未授權操作
# 這個測試檢查 serviceaccount 是否無法刪除 Pod

echo "步驟 6：測試未授權操作被拒絕..."
if ! kubectl auth can-i delete pods \
  --as=system:serviceaccount:chapter9:guestbook \
  -n chapter9; then
  echo -e "${GREEN}✓ ServiceAccount 正確地沒有 delete pods 權限${NC}"
else
  echo -e "${RED}✗ 安全性設定錯誤，不應具有 delete 權限${NC}"
  exit 1
fi

# 步驟 7：安裝測試應用程式
# 使用 Helm 安裝 guestbook 應用
# --set serviceAccount.name 指定使用自訂服務帳戶
# --set serviceAccount.create=false 避免 Helm 建立新的服務帳戶

echo "步驟 7：安裝測試應用程式 my-guestbook..."
helm install my-guestbook \
  Learn-Helm/helm-charts/charts/guestbook \
  --set serviceAccount.name=guestbook \
  --set serviceAccount.create=false \
  -n chapter9

# 步驟 8：等待 Pod 啟動
# 使用 kubectl wait 等待 Pod 進入 Ready 狀態
# --for=condition=Ready 指定等待條件
# --timeout=300s 設定超時時間為 300 秒

echo "步驟 8：等待 Pod 啟動..."
kubectl wait --for=condition=Ready pod \
  -l app.kubernetes.io/name=guestbook \
  -n chapter9 \
  --timeout=300s

# 步驟 9：驗證應用程式功能
# 檢查應用程式是否能正常存取服務
# 這個測試驗證在受限權限下應用程式仍能正常運作

echo "步驟 9：驗證應用程式功能..."
POD_NAME=$(kubectl get pods -l app.kubernetes.io/name=guestbook \
  -n chapter9 -o jsonpath='{.items[0].metadata.name}')

if kubectl exec -n chapter9 $POD_NAME -- \
  curl -s http://localhost:8080 | grep -q "Guestbook"; then
  echo -e "${GREEN}✓ 應用程式在受限權限下正常運作${NC}"
else
  echo -e "${RED}✗ 應用程式功能驗證失敗${NC}"
fi

# 步驟 10：清理測試環境
# 刪除測試應用程式與命名空間
# 保持環境整潔

echo "步驟 10：清理測試環境..."
helm uninstall my-guestbook -n chapter9
kubectl delete ns chapter9

echo "所有測試完成！RBAC 設定驗證成功。"

# 額外提示：顯示如何使用加密工具
echo
echo "額外提示：在生產環境中，建議使用 SOPS 加密 sensitive values 檔案："
echo "  $ sops --encrypt --in-place secrets.yaml"
echo "  $ helm install my-app . --values secrets.yaml"

# 這個 YAML 檔案示範如何建立 NetworkPolicy 強化網路隔離
# NetworkPolicy 與 RBAC 共同構成縱深防禦

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  # 政策名稱，描述其用途
  name: guestbook-isolation
  # 政策作用的命名空間
  namespace: production-apps
spec:
  # podSelector 選擇要套用政策的 Pod
  # 這個範例選擇所有標籤為 app=guestbook 的 Pod
  podSelector:
    matchLabels:
      app: guestbook
  # policyTypes 定義政策類型
  policyTypes:
    - Ingress
    - Egress
  # ingress 定義入站規則
  ingress:
    # 允許來自 frontend 的連線
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080
  # egress 定義出站規則
  egress:
    # 允許連線到資料庫
    - to:
        - podSelector:
            matchLabels:
              app: database
      ports:
        - protocol: TCP
          port: 5432
    # 允許連線到 DNS 服務
    - to:
        - namespaceSelector:
            matchLabels:
              name: kube-system
        - podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53

#!/usr/bin/env bash
# 這個腳本示範台灣企業如何進行 Helm Chart 安全檢查清單
# 符合金融業與高科技製造業的法規要求

# 設定錯誤處理
set -euo pipefail

# 定義檢查項目陣列
declare -a CHECKLIST_ITEMS

# 檢查函數：驗證 Chart 是否包含資源限制
check_resource_limits() {
  echo "檢查 Chart 是否包含資源限制設定..."
  
  # 檢查 values.yaml 中是否有 resources 區段
  if grep -q "resources:" values.yaml 2>/dev/null; then
    # 檢查是否包含 limits 與 requests
    if grep -A5 "resources:" values.yaml | grep -q "limits:" && \
       grep -A5 "resources:" values.yaml | grep -q "requests:"; then
      echo "✓ 資源限制設定完整"
      CHECKLIST_ITEMS+=("PASS: 資源限制")
      return 0
    else
      echo "✗ 資源限制設定不完整，缺少 limits 或 requests"
      CHECKLIST_ITEMS+=("FAIL: 資源限制")
      return 1
    fi
  else
    echo "✗ 未設定資源限制，不符合企業安全規範"
    CHECKLIST_ITEMS+=("FAIL: 資源限制")
    return 1
  fi
}

# 檢查函數：驗證 Secret 處理是否安全
check_secret_handling() {
  echo "檢查 Chart 是否安全處理 Secrets..."
  
  # 檢查是否使用 required 函式
  if grep -r "required" templates/ | grep -q "secret\|password\|key"; then
    echo "✓ 使用 required 函式強制提供敏感值"
    CHECKLIST_ITEMS+=("PASS: Secret 處理")
    return 0
  else
    echo "✗ 未正確使用 required 函式處理 Secrets"
    CHECKLIST_ITEMS+=("FAIL: Secret 處理")
    return 1
  fi
}

# 檢查函數：驗證 RBAC 設定
check_rbac_configuration() {
  echo "檢查 Chart 是否包含適當的 RBAC 設定..."
  
  # 檢查是否存在 RBAC 相關模板檔案
  if [ -f "templates/rbac.yaml" ] || [ -f "templates/role.yaml" ]; then
    # 檢查是否遵循最小權限原則
    if grep -q "verbs:" templates/rbac.yaml 2>/dev/null && \
       ! grep "verbs:" templates/rbac.yaml | grep -q "\*"; then
      echo "✓ RBAC 設定遵循最小權限原則"
      CHECKLIST_ITEMS+=("PASS: RBAC 設定")
      return 0
    else
      echo "✗ RBAC 設定使用過於寬鬆的權限"
      CHECKLIST_ITEMS+=("FAIL: RBAC 設定")
      return 1
    fi
  else
    echo "✗ 缺少 RBAC 設定檔案"
    CHECKLIST_ITEMS+=("FAIL: RBAC 設定")
    return 1
  fi
}

# 檢查函數：驗證 NetworkPolicy
check_network_policy() {
  echo "檢查 Chart 是否包含網路隔離政策..."
  
  if [ -f "templates/networkpolicy.yaml" ]; then
    echo "✓ 包含 NetworkPolicy 設定"
    CHECKLIST_ITEMS+=("PASS: 網路隔離")
    return 0
  else
    echo "⚠ 缺少 NetworkPolicy，建議新增以強化安全"
    CHECKLIST_ITEMS+=("WARN: 網路隔離")
    return 1
  fi
}

# 檢查函數：驗證容器安全上下文
check_security_context() {
  echo "檢查 Chart 是否設定安全上下文..."
  
  if grep -r "securityContext:" templates/ | grep -q "runAsNonRoot\|runAsUser"; then
    echo "✓ 設定容器安全上下文"
    CHECKLIST_ITEMS+=("PASS: 安全上下文")
    return 0
  else
    echo "✗ 未設定安全上下文，容器可能以 root 執行"
    CHECKLIST_ITEMS+=("FAIL: 安全上下文")
    return 1
  fi
}

# 主執行流程
echo "================================================"
echo "  台灣企業 Helm Chart 安全檢查清單"
echo "================================================"
echo ""

# 依序執行各項檢查
check_resource_limits
echo ""

check_secret_handling
echo ""

check_rbac_configuration
echo ""

check_network_policy
echo ""

check_security_context
echo ""

# 產生檢查報告
echo "================================================"
echo "檢查結果摘要："

# 統計各類結果的數量
PASS_COUNT=0
WARN_COUNT=0
FAIL_COUNT=0

for result in "${CHECKLIST_ITEMS[@]}"; do
  if [[ $result == PASS:* ]]; then
    ((PASS_COUNT++))
  elif [[ $result == WARN:* ]]; then
    ((WARN_COUNT++))
  elif [[ $result == FAIL:* ]]; then
    ((FAIL_COUNT++))
  fi
done

# 計算合規率
TOTAL=$((PASS_COUNT + WARN_COUNT + FAIL_COUNT))
if [ $TOTAL -gt 0 ]; then
  COMPLIANCE_RATE=$((PASS_COUNT * 100 / TOTAL))
else
  COMPLIANCE_RATE=0
fi

echo "通過項目：$PASS_COUNT 項"
echo "警告項目：$WARN_COUNT 項"
echo "失敗項目：$FAIL_COUNT 項"
echo "合規率：$COMPLIANCE_RATE%"

# 根據檢查結果提供建議
echo ""
echo "建議措施："

if [ $FAIL_COUNT -gt 0 ]; then
  echo "- 立即修正所有失敗項目，否則不應部署至生產環境"
fi

if [ $WARN_COUNT -gt 0 ]; then
  echo "- 優先處理警告項目，強化整體安全架構"
fi

if [ $COMPLIANCE_RATE -ge 80 ]; then
  echo "- 合規率良好，可考慮部署至測試環境驗證"
elif [ $COMPLIANCE_RATE -ge 60 ]; then
  echo "- 合規率尚可，建議完成所有修正後再部署"
else
  echo "- 合規率偏低，需要大幅改善安全設定"
fi

echo ""
echo "注意：本檢查清單符合台灣金融業與高科技製造業資安規範要求。"
echo "實際部署前請依據企業內部政策進行完整資安審查。"

# 根據結果決定結束碼
if [ $FAIL_COUNT -gt 0 ]; then
  echo ""
  echo -e "${RED}安全檢查未通過，請優先處理失敗項目！${NC}"
  exit 1
else
  echo ""
  echo -e "${GREEN}安全檢查通過，符合基本安全要求。${NC}"
  exit 0
fi