ref: https://itnext.io/helm-3-secrets-management-4f23041f05c3

Secret Management 的議題一直以來都是 CI/CD 流程中不可忽似的一部分，本篇文章作者不同於以往採用常見的解決方案(Hashicorp Vault, Helm Secret, SealedSecret)，反而是使用 Helm 內建的 AES 加解密功能來實作 Heml Chart 資料的加解密需求。

作者認為一個良好的機密管理解決方案需要能夠為其團隊提供三個基本需求
1) 所有的機密資訊都要能夠存放到版本控制系統中(Git...etc)
2) 所有被上傳到 Chartmuseum 的 Helm Chart Package 都不能有任何 k8s secret 物件，要放的只能有加密後結果。反之使用者要使用時也必須要有能力去解密
3) 單一工具管理，以作者來說會希望能夠都使用 Helm 這個工具來處理，愈少的工具意味者依賴性愈少，同時在維護與管理上要花的心力也更少。

作者首先列舉了兩個現存的專案，分別是 Helm Secrets 以及 Hashicorp Vault 並且針對這兩者進行了簡單的介紹，並且舉出為什麼這兩個專案並不適合作者團隊的需求與使用情境。

作者最後開始認真研究 Helm 本身有什麼內建的加解密功能可以使用，最後發現 encryptAES 以及 descryptAWS 這兩個內建函式可以使用，譬如

value: encryptAES "secretkey" {{ .Values.valueToEncrypt }}
value: {{ .Values.valueToDecrypt }} | decryptAES "secretkey"

有了基本的概念與用法後，作者透過 shell script 實作一層 wrapper 來簡化整個處理流程。
最後將這些資訊也導入到 CI/CD 流程中來幫忙進行解密的相關動作，讓 CD 可以順利的將目標 Secret 給送到 Kubernetes 中。

個人心得: 採用加解密的系統個人還是喜歡採用 SealedSecret 的設計理念，將解密的時間點延後到 Kubernetes 內而並非 CI/CD 系統上，主要是 CI/CD 的 pipeline 要是沒有仔細設計其實很多人會不小心把過程命令給輸出的，這樣的話加解密的過程，使用的 Key 等都有可能會洩漏出去。

本篇文章是ㄧ個 Kubernetes 相關工具經驗分享文，作者認為即使是前端開發工程師也必須要瞭解一下 Kubernetes 這個容器管理平台，作者認為 k8s 基本上已經算是這個領域的標準(de-facto)。

因此作者於本篇文章介紹一些搭建一個 K8s 叢集時需要注意的工具，透過這些自動化工具來減少反覆動作的執行藉此簡化每天的工作流程。

工具包含
1. ArgoCD
2. MetalLB
3. External-secrets
4. Cert-manager
5. External-dns

Simplify deploying of new apps
作者大力推薦使用 ArgoCD 來簡化部署應用程式，作者提到一開始使用 ArgoCD 時也是感到無比煩感，因為心中一直存在要於 `GitLab CI/CD pipeline` 透過 kubectl apply 的方式來部署應用程式，並不想要導入其他的元件來加入更多的複雜性。

然而當作者嘗試 ArgoCD 後，第一眼發現的是其架構不如想像中複雜，完全依賴 GitOps 的原則來簡化整個部署流程，同時透過一個 WebUI 的方式來呈現當前應用程式的部署狀況

Load balancer for your on-prem clusters
地端環境的 Load-Balancer，沒什麼好說就是 MetalLB。

Managing your secrets
Secrets 是 Kubernetes 內一個非常重要的物件，然而大部分的團隊都會思考如何有效且安全的去管理 Kubernetes 內的 Secret 物件。雲端供應商譬如 AWS Secrets Manager, Azure Key Vault 或是廣受熱門的 HashiCorp Vault.

作者推薦使用 external-secrets operator 這個專案來將外部的管理系統給同步到 Kubernetes 內並且產生對於的 secrets。

詳細全文可以參考下列原文

https://chris-blogs.medium.com/tools-that-should-be-used-in-every-kubernetes-cluster-38969ed3e603

今天分享的是由 CloudBees 所分享的 DevOps 議題，
GitOps 的世界中，該如何做好 Secret Management ?

原文連結: https://cd.foundation/blog/2020/11/05/gitops-kubernetes-and-secret-management/

該影片提到幾個重點
1. Git 本身的設計不是用來純放與共享 Secret 等資訊
所以千萬千萬不要於 Git 內去存放 Secret 物件，因為他只有編碼，沒有加密。

有不少的流派方式可以用來管理 Secret Management，譬如說
1. Sealed Secrets 該專案的流派，實實在在的加密敏感資訊，並且把加密後的結果存放到 Git 專案中，當這些物件被套用到 Kubernetes 內時，會有對應的 Controller 去解密，並且產生最後的 Secret 物件
評論: 這種流派下就要特別注意該加解密的 key 不能外流，並且要定期 rotate

2. 打包 Image 的時候直接將相關的機密資訊一起打包，這樣使用時完全不需要外力介入，直接使用。
然後這種情況帶來的問題很多，缺乏彈性，image 本身變得非常危險，要花更多心力去確保 Image 不會外流。極度不推薦這種走法

3. 透過外部的 External Secrets Management 平台來管理，譬如使用由 Godaddy 所開源的 kubernetes-external-secrets 專案，該專案後端支援 AWS Secrets Manager, AWS System Manager, Hashicorp Vault, Azure Key Vault, Google Secret Manager 等眾多項目，並且提供一個統一介面給 Kubernetes 使用。 Kubernetes 中透過 ExternalSecrets 的方式就會觸發 Controller 去存取相關的機密資訊，並且轉成 Secret 物件供容器使用

有興趣的人可以點選下方連結觀賞完整影片，大概 20 分鐘左右，非常適合邊吃飯邊看