# 透過Hashicorp Vault與K8S集成案例，探索零信任安全身份認證策略 - William Yang

{%hackmd @DevOpsDay/BJXaW1_k6 %}

- 過去保護數據中心很直接
- 可信邊界(Trusted perimeter)
- 內部是在防火墻內被保護的
- 可信訪問(Trusted access)
- 受保護的數據(Secured data)

- 保護現代基礎設施很難
- 沒有可信邊界
- 上雲了，邊界變模糊
- 沒有受信任的訪問
- 不安全的數據

- 數字安全性(Cybersecurity)漏洞
- 過去兩年盜竊事件的數據增加 380%
- 82% 違規行為涉及人為因素
- 90% Web 應用程式洩漏(包括憑據被盜)
- 62% 系統入侵(涉及供應鏈)

> Case:
> 某公司把 access key 放到 source code 並放到 git 的 private repo，後續修正時忘記刪除 history 導致資料被竊取

## 零信任安全(Zero Trust Security)
核心思想：「永遠不要去信任，要始終驗證一切、授權一切，並且傳輸過程中的數據要加密保護」

- HashiCorp 認為零信任安全的基礎為**身份(Identity)**
- 不管人、服務、機器都有多重身份，所有的驗證都在驗證其身份
- 一套基於 Identity 的系統必須要能回答這些問題：
- **Who**: 他是誰？
- **Where**: 他從何處驗證？
- **When**: 他於何時驗證？
- **How**: 他是用什麼方式驗證的？
- **What**: 他能夠做些什麼？
- **Why**: 為什麼他要做這些？

- Legacy Identity was Simple(過去)
- 應用程式和網路透過基於受信任網路上的靜態 IP 地址進行保護
- 通常有一個登錄系統提供用戶訪問系統和資源

- Modern Identity is Complex(現在)
- 用戶有太多方法及途徑去登入不同系統
- 系統太多不便於管理

## 零信任安全(Zero Trust Security) with HashiCorp
推出 HashiCorp Vault 來解決 Zero Trust Security Identity Complex 的問題

- HashiCorp Vault
- 簡化所有平台的身份識別
- 將用戶的多種身份集中起來變成一個 Entity 和一套屬於自己的 Identity 來對應其不同的應用程式
- 基於身份驗證來決定能做什麼
- 可以代理跨應用程式、網路和用戶的所有身份，然後依據身份保護一切

> 講師舉例：進到 HashiCorp Vault 做身份驗證之後，相當於得到了一個你自己的 passport，再依照該 passport 來決定你能夠去哪裡、做些什麼？

- HashiCorp 專注在 Zero Trust Security 三個面向的問題
- Applications + Identity
- 處理 machine 驗證(authentication)和授權(authorization)的問題
- 確保應用程式可以訪問其他應用程式和數據庫
- 應用程式數據在傳輸以及儲存時始終是安全的
- Networking + Identity
- 處理 machine access 和 application access 的問題
- 確保哪些服務可以訪問其他人以及被訪問
- 跨雲和數據中心的網路流量始終是安全的
- Users + Identity
- 處理 user 到 machine 的 connection 問題
- 確保用戶可以訪問哪些系統
- 會話和訪問數據始終是安全的

- Multi-cloud security in a "Zero Trust" world
- Machine Authentication & Authorization
- HashiCorp Vault
- Machine-to-Machine Access
- HashiCorp Consul
- Human-to-Machine Access
- HashiCorp Boundary
- Human Authentication & Authorization
- 其他 Third-Party Single Sign-On(SSO)
- Platform
- HashiCorp Terraform

> 以上都是基於身份(Identity-Driven Controls)

## 強化 DevOps 安全性：整合 HashiCorp Vault 與 Kubernetes
整合 HashiCorp Vault 和 K8S 大致有 4 種方法

### API Based and Programming Library
- 優點
- 自由度非常大
- 幾乎所有動作都可以透過 API 來完成

- 缺點
- 產品開發的開銷非常大
- 應用程式必須懂得和 Vault 交談
- 輪詢密碼、Rotate Secret
- Restart 應用程式
- Disconnect, Connect, Restart Database
- 動態管理私鑰、管理 token 的生命週期 Time To Live(TTL)

### CSI Provider
> 因為較少人用所以講師跳過未談

### Vault Agent
- Overview flow
1. 在 K8S 放 sidecar injector
2. 在 deploy Pod 前會嵌入一個 Initial Container
3. Initial Container 從 Vault 取最初的密碼
4. 將最初的密碼放到 path/volume 底下
5. 再啟動一個 Vault Agent Container 用來更新密碼
6. 程式 Detect 到之後便可進行 Refresh

- How Vault Agent works
- Auto-Auth
- 直接透過 Agent 跟 Vault 做驗證，應用程式就不用再去跟 Vault 做驗證溝通
- Caching
- 儲存 TTL 尚未到期的 Secrets 方便使用者直接取用
- 速度快且可減少 Vault Server 的負擔
- Templating
- Secrets Script Engine
- 可嵌入自定義的 Script
- 可對收到的 Secrets 做一些特殊操作

- 優點
- 減少或者完全消除應用層面的重構(refactoring)
- 將機密資料存放至檔案系統或環境變數
- 利用現有流程以及專業知識加快 develope 和 deploy 的速度

- 缺點
- 還是把 Secrets 放在顯而易見的地方(local file 或環境變數)
- 如何解決第一次嵌入 Secrets 的安全性問題

- Vault Agent Injector 所面臨的問題
- 每個 Pod 都有一個 Agent Sidecar 因此資源開銷龐大
- Vault 要存每個 Pod 的 token 和 Secrets，資源開銷也很大
- Pods 有 Vault 運行時間的依賴性，如果 Vault 掛了，Pods 就啟動不了
- K8S 工作負載為 **"Vault Aware"**
- 跨 Pods 的更新不是協同的

### Vault Secrets Operator(VSO)
在 K8S 做一個 Centralize 的 Vault Agent
在 Distribute 時不是放到某個 File 而是放到 K8S 的 Native Secrets

- Overview flow
1. 在 K8S 放一或多個 VSO
2. VSO 到 Vault 上取 Secrets
3. VSO 將 Secrets 按照要求丟到不同 Namespace 產生 Native Secrets
5. K8S 原生的 Applications 就可以直接讀自己 Namespace 底下的 Native Secrets 而不用去懂 Vault 怎麼做
6. VSO 中心化管理 Secrets 和其 TTL
7. Secrets Rotation 只需透過 K8S Rollout

- 將 Secrets 丟到 Namespace 時支持 Custom Resource Definitions(CRDs)
- VaultConnection
- 標示 Vault Server 在哪，可以在 K8S 上也可以在外部
- VaultAuth
- 設定驗證方式
- VaultStaticSecret
- 設定 Secrets 要放在哪裡的 K8S Static Namespace
- VaultDynamicSecret
- 設定 Secrets 要放在哪裡的 K8S Dynamic Namespace
- VaultPKISecret
- Rollout Restart Targets
- 設定 Rollout 的 Configuration

> 以上都是透過 .yaml 檔案做設定

- 優點
- 每個 Pod 不再有額外資源開銷
- 租約數量減少，降低 Vault 的資源開銷
- Vault 掛掉時，Pod 依舊能使用
- K8S 工作負載是 **"Vault Unaware"**
- Rollout 透過 Native 方式來做(比較輕鬆且較不受干擾)

> 感覺有點怪怪的，Vault 所使用的資源不是還是取決於 Pods 數量嗎? [name=Crescent Hsieh]

- 缺點
- K8S Native Secrets 是 BASE64，並不是加密的
- 目前不支援自定義 Scripts
- 加密得自行加密(?)

---
## Old Notes
> 抱歉，共筆的各位，我不小心刪到了前面一些些的 Notes :( [name=Crescent Hsieh]

- API Based and Programming Lib
- good
- 利用 hashCorp Eng, OSS 社群進行更新/修復
- 強制多個 applications/ busnisses 實施標準的 Vault 存取模式
- 開發者 friendly 的模式和緊密的應用層命整合
- concern
- 需要對某些應用進行重構或捆綁由您的組織管理的 lib / module
- 應用程序必須處理：
- 管理 Vault 令牌的生命週期
- 管理動態機密的租約
-
- CSI Provider
> 因為較少人用所以講師未談
- Vault Agent
- 現在最流行的方法

- 在起你的服務前額外起一個 container 去索取密碼，並且在你的 k8s 額外起一個 Vault agent sidecar 去跟 Vault 做確認

- 3 features
- auto auth:
- 自動認證至 vault
- caching:
- 儲存尚未TTL的Sercet以方便User再次讀取並減少Server壓力
- templating
- 可加入自定義 Scripts

- good:
- 減少應用層面重構
- 將機密存在環境變數或是檔案系
- 利用現有流程和知識，促進廣泛和多樣化的應用組別互動
- concern
- 需要考慮如何解決初次的vault令牌的"機密0"或"安全引入"的問題

- 面臨的問題（使用量越大 產生 問題越嚴重）
- 每個 k8s Pod 的 k8s 資源的開銷，每一個Pod 會有一個 Agent Sidecar
- 啟動 Pods 有 Vault 的運行時間依賴性，有先後順序問題
- 每個 pod 的 vault 開銷
- kuberbetes 工作覆載是 vault aware
- 在每個node 的 每個pod所使用的vault資料 可能會不同步問題
- Vault Secret Operator(VSO)(最新的)
- 透過 VSO 將 Vault Secret 同步到 k8s secret
- Application 直接向 k8s 存取 secret 不用再找 Vault
- 直接從 kubernetes 訪問其 secrets 不需要知悉 vault
- k8s 和 vault 都有較小的開銷

### 總結
- 無每一個 pod 的 k8s 開銷
- 無 pod 的時間依賴性