2021 11 16 Ithome Cloud Summit Vault

Last updated on Sep 11, 2023 5 min read Technology

各位好

關於這個 QRcode

每次上台前，我都會想要帶什麼樣的內容給觀眾，讓觀眾值得花 30 分鐘在底下聽。後來就習慣先發表一篇文章，把對觀眾有幫助的資源包成一包：

  • 首先是完整投影片：https://slides.com/chechiac…/terraform-introduction-a56697
  • 逐字講稿：(最後校稿中）
  • 然而只有本次演講內容，回去可能還是不太容易操作。所以這次附上使用 Terraform 一鍵部署 vault 的 Github Repository：https://github.com/…/southe…/chechia_net/vault/singleton
  • 如果不熟 Terraform，再附上 30 天手把手 Terraform 教學文章，只要願意花時間，全篇中文一個月帶你上手 Terraform。
    • IThome 鐵人賽好讀版：https://ithelp.ithome.com.tw/users/20120327/ironman/4057
    • Github Repository 完整版：https://github.com/…/terraform-30…/tree/main/lecture/zh
  • 如果遇到問題還是需要找人發問，所以再推薦兩個社群，可以來這邊發問，要找我本人也找得到。甚至只是加入潛水不講話，都可以被動吸收許多新知。

大家可以手機拍完這個就出去吃午餐了。 或是拍回家，然後傳給一個同事叫他花 30 天把 Terraform 跟 Vault 這些都學會。

總之希望對各位有幫助，讓國內技術力能持續進步成長。

回到本次演講。

本次演講有三個關鍵字

  • Kubernetes
  • Vault
  • Terraform 這個是隱藏的

請問平時工作會用到這三個技術之一的朋友，請舉個手，好讓我知道一下觀眾的分布，等等分享的內容會照比例做一些調整。

我們今天不會講太多 Kubernetes 的內容，重點放在 Vault，以及如何設定 Vault，所以 Terraform Infrastructure as Code 或是 configuration as Code 會在這邊跑出來。

關於我，我是哲嘉。我在 Maicoin 當 SRE。常出現的社群是 CNTUG 與 DevOpsTW。

我們今天談的更大的主題其實是 Key Management 私鑰管理，或是密碼管理。這是一個很大的題目，今天演講內容只是其中的一個實作案例。

舉個例子，一邊是 API Server，另一邊 Database，或是第三方服務

Database 來 Authenticate 合法的 Client 用戶端，可能是 username + password，或是 API Key + Secret，或是 Access Token，或是 Private Key，Client Certificate，都可以。

在跨不同平台或是介面的服務，我們常用的 Auth 方法。認 Key 不認人。

那中間這些 Key 要怎麼管理，就有很多學問 其中最基本的，是怎麼配置給 API Server 讓他使用 注意：讓 API Server 使用，隱含的意思是，其他人不管是其他微服務，或是開發工程師，閒雜人等都不能看到。

這邊我們假設 API Server 是在 Kubernetes 裡面跑，微服務架構，所以 API Server 可能是一個 Pod，我們 SRE 要為這組 Pod 配置密碼。

這邊列出的應該是 K8s 比較常見的幾種做法。

  • plain text，直接寫進 file 讓 Pod 去讀取
  • k8s secret 做 base64 encode
  • 安全一點的透過外部機制作加密解密
  • 或是寫在 API Server 的 memory 中

事實上如果沒有使用 K8s，使用 VM 或是公有雲 Container Service，應該都是類似的原理，大家都是 Linux base，secret 放進來看要放在 disk 或是 memory 裏面。

實際放到 K8s 大概會長長這些 yaml

最簡單，就直接把 secret 壓到 Pod env 裏面，

最簡單也最危險

  • 所有看得到 yaml 的人都明碼看見密碼
  • 所有能進到 file system

提外話

API Server 被從正面打穿，滲透到拿到這組密碼的機會多高？

  • 如果 API Server golang library 有在跟安全性更新
  • Kubernetes 用公有雲的 Kubernetes Service，有在更新
  • OS ami 跟 docker image 都有在更新
  • 然後有功能正常的防火牆

打掛蠻有可能的，但打穿服務到拿到密碼，是有難度的。

更多時候，至少在幣圈有被爆出來的資安事件，大多是是公司員工被釣魚信掉到，被植入惡意軟體在 local 電腦，然後他又看得到明碼的密碼，直接爆炸。

明碼糟糕的地方，大家都看得到，一開始就是 exposed 的狀態，風險不可控，也無從管制。

然後是 K8s secret，也是從 env 掛進去 Pod

放在 k8s secret，是 base64 的格式

看起來跟原先內容不一樣了，有人就跟我說，他們家的 k8s secret 有用 base64 加密。

encode 跟 encrypt

k8s secret 有什麼問題

  • 明碼 plain text 的問題，不該看到的人很容易就看到
  • 根本的問題還是 RBAC 懶得設定，大家都用 default role 進來

要用可以，先看 k8s secret 後面的儲存實作是什麼？

  • 是 k8s etcd
  • 透過 k8s API server 存取

etcd 跟 kube-api 一般來說是夠安全的。官方文件還建議

  • secret 要加密 encrypt
  • 增強 RBAC 控制，只有特定 role 才看得到 secret，，而不是每個人都用 default role 近來 k8s，然後進到 namespace 全部 secret 就看光光

RBAC 有設定好，有加密，是可以做到安全。當然還是沒有專門 key Management 工具，如 Vault 有額外管理上的優化功能。

加密範例可以看強者我朋友的文章

加密完可能長這樣，還要額外透過其他機制才能進行解密，拿到原始資料

  • 例如透過 k8s controller 解密
  • 或是透過 vault server
  • 或是透過公有雲的 Key Management Service 做解密

其他的 k8s secret 加密解決方案

今天我們使用 Vault，其中一個目的就是要坐中間這段 Safe Magic

  • 給這個 Pod secret
  • 然後只給這個 Pod Secret

當然 Key Management 其他還有一堆事情要處理

  • 密碼洩漏的話有沒有 revoke 機制

  • 能不能定時 Rotate 汰換密碼？

  • 改架構，底下的設定好不好耕著動態調整，還是要跟著 rename / mv k8s secret

  • 怎麼做稽核，怎麼檢查內容。我看不到 vault 幫我看一下內容對不對，這個很容易發生。

臆想頭就很痛

今天的目的很單純

  • 密碼的露出盡量小
  • 最好密碼是有期限的，逾期自動失效
  • 暴露了可以 revoke

Vault

有人用過？這邊簡介一下

在 CNCF 的 landscape 漱渝 Key Management，應該是裡面市佔最高的開源項目

重點就是保護與管理 secret

Vault 的核心概念，這個影片是 Hashicorp 官方介紹的影片，講得很好，大家自己回去看一下

這邊簡單 vault 101

現在有一台 vault server 已經設定好了，我們可以使用 vault client 連線

例如這邊

  • 使用 VAULT TOKEN 告訴 vault 你是什麼身份的用戶
  • 或是進行 login，Vault 會呸發一組臨時的 TOKEN 給你

拿著組 TOKEN 去問 Vault，請問我可以要 /user/mysql 這個路徑下的資料嗎？

Vault 檢查 TOKEN 的 role 與 permission，可以就回傳值 不行就 permission denied

Vault 就是金庫，真正重要的 key 存在裡面，使用這要來問 Vault，要先過 Vault 這關

Vault 實際存放 Secret Engine，這邊也跳過，大家先把他當 key / value 存放好了 XD

等等，這樣 vault Auth 有點怪

本來拿 username / password 去控制 Mysql 先在多一步，先拿到 VAULT TOKEN，再拿 TOKEN 去跟 Vault 拿 Mysql password，再去連 MySQL

咦這樣不是很怪？我如果 Vault token 暴露了，有心人士還是可以從 vault 拿到資料啊

這樣有比較安全嗎？還是只是花式被駭

對，只是做 token 交換的話，還是不夠，所以 Vault 有提供許多 Auth method

  • token 只是其中一種
  • 有很多認證方法不用 token 交換，但也能讓 vault 認得 k8s pod 與 api server

這是今天的重點之一，token / 密碼傳遞不安全，那就用其他手段 auth

以 AWS IAM auth 為例

如果今天是在 aws ec2 上跑，那可以透過 aws internal api 去取得身份認證資料，也就是 ec2 instance metadata

拿這個 metadata 去問 vault，vault 再透過 aws api 去確認，這個 ec2 instance 真的是合法的

然後依據 ec2 instance 身份，配發權限跟資料

  • api server ec2 就給 api server secret
  • frontend server ec2 就給 frontend secret

中間沒有多餘的密碼 / token 交換

來往的對話大概是這樣

  • AWS API 是可信的
  • Vault 自己維護是可信的
  • 服務透過三方交握去認證，認 runtime 環境的 metadata，不再是認 key 不認人

至於 api server ec2 近來 vault 後，應該有什麼樣的權限，在 vault 內部透過 policy 配置

  • 設定 path
  • 設定允許的 operation 例如 read write list delete … 等

runtime 動態調整

當然 Vault 還有提供很多更加安全的功能

  • 例如如何安全地存放 secret

Storage 這邊跳過

Secret + auth 搭配跳過

以及 dynamic secret，來解認 key 不認人的問題

例如 mysql 的靜態 username / password，透過 vault 設定可以變成動態的

回到 k8s，使用 token auth，然後把 VAULT TOKEN 放在 k8s secret 裏面，只有比較安全一點點

就是 VAULT TOKEN 可以快速 rotate 跟 revoke

這邊可以搭配其他 auth 方式來解決

剛剛不是讓 vault 去認 aws ec2？

在 k8s 中，可以讓 vault 去認 k8s cluster / service account

路徑圖長這樣

  • pod runtime 都會有 service account
  • 使用 service account 的 metadata 去問 vault
  • vault 去問 k8s，這個 service account 是真的假的
  • k8s 回答 vault，Pod 跟service account 是合法的
  • vault 再配權限給 Pod

auth detail 的文字描述，跟上面講的一樣

配合 k8s sidecar，可以把 vault 拿到的 key 寫到 memory mount 裏面

  • Pod init 時 init container 才去 invoke vault API
  • key 不會透過 k8s api 傳遞，也不會在 etcd 內出現
  • main container 透過 memory mount 存取 key
  • key 的 lifecycle 跟 pod 一樣， pod delete 掉這組 in-memory key 也自動清除

好處

  • 更少 expose，沒有過 kube-api 與 etcd
  • in-memory
  • vault 跟 pod 之間的 vault token 的 time-to-live 期限可以很短，幾十秒內，init 完即可拋棄的 token

壞處（？）

  • 每個 pod 起來會去打 vault api
    • 實務經驗上 loading 很低
    • 而且 vault server 可以做 HA 跟 horizontal scaling
  • 最大的成本，其實是 vault 設定
    • 讓 vault 認 k8s
    • 根據 service account 去配權限
    • 其他花俏功能都需要額外的設定
    • 系統複雜，保證配到你頭昏眼花

想像一下，這張圖里的

  • policy 跟為服務數量呈正比
  • secret path 也耕服務數量呈正比
  • auth k8s 數量也跟服務數量呈正相關
  • 用越久，內容隨時間增加
  • 改架構時更刺激

建議使用 vault 務必 搭配 Terraform 管理

  • infrastructure as code
  • configuration as code
  • policy as code

Terraform 非常適合管理複雜，但有常常需要細部調整的設定資料

其他功能，跳過

其他功能

secret debug 超麻煩

  • 內容正確性，valid key 還是 invalid key，還是根本是另一隻 key
  • 權限正確性，是不是這個 username / password 的權限是正確的
  • 跨團隊溝通更頭痛，不是可以貼在 slack 大家一起幫看的東西

terraform 可以幫助 vault 設定 debug

  • 至少跨環境復現問題很方邊

Vault 有 HA

Vault Performance 通常不是問題

  • 雖然 loading 隨 micro service 線性增加
  • 但本身可以是無狀態 server，可以 horizontal scale

注意一下 auto-retry

  • pod fail restart 又再 init 一次，如果一萬個 pod 一直 retry 可能真的會把 vault 打爆
  • backup limit 要注意
  • 使用 init container 的話，是 cache 在 Pod 層級，container fail restart 不會重新打 vault api

安全性

  • vault 有專業資安團隊把關
  • 不要怕 vault 被打穿，而是要怕同事被釣魚

結論

要不要 vault

qrcode 最後機會

有問題可以來社群找我

Maicoin 是間好公司 2014 服務上線到現在，在台灣已經邁入第八年。顧客數一直增加，我們也持續緩慢擴編。

覺得自己有能力，歡迎來挑戰，等等私下找我聊

謝謝

Q & A

Terraform vs Pulumi

  • 操作語言差異，有好有壞
  • vault 跟 terraform 的 hcl 是增強版 json，本質還是 json，有興趣可以去看我的文章
  • terraform 目前是站跟星星還是領先，未來繼續看

Kubernetes Service account token 要不要更新

  • 要，應該定期更新，官方文件有操作步驟

Vault / Terraform 實務上的工作負擔會很花時間跟人力嗎

  • 學習曲線比較奇怪，要花一點時間做中學
  • 學熟了之後就很好改，效率很高
  • 至少是屌打用 gui 改或是 client 直接下 cmd 拉
kubernetes vault terraform
Che-Chia Chang
Che-Chia Chang
Site Reliability Engineer

My research interests include Site Reliability Engineering, DevOps, Container and Kubernetes.