● 前言

在雲端原生環境中，敏感資訊（例如資料庫密碼、API Key、TLS 憑證）是系統運作的核心。
若管理不善，就等於把系統鑰匙交給攻擊者。
Kubernetes 提供了 Secret 物件來集中管理敏感資訊，但它本身並不是一個足夠安全的解決方案。

● 為什麼Kubernetes Secret需要加密存放？

1.Base64 只是編碼

Secret 預設使用 Base64 存放內容，這只是「編碼」，不是加密。
任何人只要有權限 kubectl get secret，就能直接解碼看到明文。

2.etcd 須額外保護

Secret 最終是存在 etcd 資料庫中。
若沒有設定 etcd 的磁碟加密，入侵者可以直接從硬碟 dump 出明文資料。

3.GitOps 的挑戰

我們常常把 K8s YAML 檔放在 Git Repo。
若 Secret 直接以明文存放，等於是把敏感資訊放在版本控制裡（GitHub、GitLab 甚至公開）。

👉 因此，K8s Secret 需要額外的加密與保護機制。

● 常見工具

1.Sealed Secrets:由 Bitnami 提供的控制器（Controller）。

▪流程：

使用 kubeseal CLI 將 Secret 加密 → 存放到 Git。
部署到集群後，Controller 會自動解密，還原成原生的 Secret。

▪優點：

Git 中只有加密版本，不怕外流。
解密只會在集群內進行，外部人拿不到私鑰就無法還原。

2.Mozilla SOPS (Secrets OPerationS):一個專門設計來管理加密檔案的工具。

▪特點：

可與 GitOps 工具（ArgoCD、FluxCD）整合。
支援多種 Key 管理：KMS（AWS、GCP、Azure）、PGP、Age。

▪使用方式：

sops -e secret.yaml > secret.enc.yaml
透過 KMS 或 PGP key 在需要時解密。

● 實作範例：Sealed Secrets

🗂️專案目錄:

▪實作步驟：

1.建立原始 Secret

# 例：使用 demo 命名空間；若用 default 就把 -n demo 拿掉
kubectl -n demo create secret generic my-db-secret \
  --from-literal=username=admin \
  --from-literal=password='s3cr3t' \
  --dry-run=client -o yaml > k8s/secret.yaml

👉記得把 k8s/secret.yaml 加到 .gitignore，避免誤上傳。

2.使用 kubeseal 加密

不落地明文（更安全）：

kubectl -n demo create secret generic my-db-secret \
  --from-literal=username=admin \
  --from-literal=password='s3cr3t' \
  --dry-run=client -o yaml \
| kubeseal --format yaml --namespace demo --name my-db-secret \
> k8s/sealed-secret.yaml

👉--namespace 與 --name 會被寫死到密文中，後續套用時必須一致；換 namespace/name 就要重封印。

3.SealedSecret 範例

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: my-db-secret
  namespace: demo
spec:
  encryptedData:
    username: AgA...   # 很長一串密文
    password: AgB...

4. 套用並驗證

# 套用加密檔（Controller 會在叢內解密並產出原生 Secret）
kubectl apply -f k8s/sealed-secret.yaml

# 確認 Secret 真的被建立
kubectl -n demo get secret my-db-secret

#（可選）解碼其中一個欄位確認值是否正確
kubectl -n demo get secret my-db-secret -o jsonpath='{.data.username}' | base64 -d; echo

🔔namespace 與 name 綁定：預設 scope 是 strict，metadata.name/namespace 任一變動都需重封印（可用 --scope namespace-wide/cluster-wide 放寬，但要評估權限風險）。

🔔跨叢集需重封印：每個叢集的公鑰不同；換叢集或金鑰輪替後，要重新 kubeseal。

● 總結

🔹Kubernetes Secret 不是加密，只是 Base64 編碼。
🔹若要安全管理敏感資訊，必須結合 GitOps + 加密工具。
🔹Sealed Secrets：適合 Kubernetes Controller 自動解密的場景。
🔹SOPS：更通用，能與 KMS/PGP 結合，適合多雲環境。

最終目標是：Secrets 應用安全要從「明文管理」走向「加密 GitOps 流程」

👉 下一篇 Day 29｜DevSecOps 全貌：把安全融入 CI/CD 的完整流程