credential

HashiCorp 的 Vault 也有 fork 了：OpenBao

當初 HashiCorp 宣布改 license (可以參考之前寫的「HashiCorp 將放棄 Open Source License，改採用 BSL 1.1」)，用的最多的 Terraform 就馬上有人 fork 出來：「OpenTF 宣佈從 Terraform 最後一個 Open Source 版本 fork 出來」、「OpenTF (Terraform 的 fork) 改名為 OpenTofu」。

而 Vault 也受到影響，當時花了一些時間找看看有沒有人 fork，沒找到後就改用 etcd (然後搭配 etcd-adminer 以及 oauth2-proxy 接 Google Workspace 的 SSO)，後來就沒有追這個問題了...

剛剛才看到 fork 的消息出來了：「OpenBao – FOSS Fork of HashiCorp Vault (github.com/openbao)」，專案在「OpenBao」這邊，要注意目前只有 development branch 有東西，main branch 目前是空的，而且 Hacker News 上討論也有提到現在還在 early stage，很多東西都還在整理。

之後有機會再回來看看...

測試 GitHub 與 AWS 可以多快偵測出外洩的 token

前幾天在 Hacker News 上看到「What happens when you leak AWS credentials and how AWS minimizes the damage (xebia.com)」這篇，原文連結在「What happens when you leak AWS credentials and how AWS minimizes the damage」這邊。原文跟 Hacker News 上的寫到東西都頗有趣的，可以分開來講。

先是原文的部份，他抓了一些時間軸：

12:33:12 – Pushed the credentials to GitHub
12:34:19 – The AWSCompromisedKeyQuarantineV2 policy is attached to the IAM user test-user by AWS
12:34:32 – Various List and Describe calls are made using the leaked credentials
12:35:08 – Received an email from AWS with the subject ‘ACTION REQUIRED: Your AWS Access Key is Exposed for AWS Account 12345678’

可以看到推上 GitHub 後，AWS 在一分七秒後就自動加上 AWSCompromisedKeyQuarantineV2 以減少災害擴大，然後再發信件通知。

這個功能可以參考 GitHub 的文件說明：「About secret scanning - GitHub Docs」。

另外在 Hacker News 上面看到有人直接把 secret scanning 當作 API 串來用 (噗)，把在 PyPI 上面掃到的 AWS secret 丟上 GitHub 觸發後續的機制：

I set up a project[1] to automatically leak AWS secrets published to the Python package index, which then triggers the secret scanning process and quarantines the keys[2]

1. https://github.com/pypi-data/pypi-aws-secrets

2. https://github.com/pypi-data/pypi-aws-secrets/blob/main/keys...

在 AWS Summit Taiwan 2021 上講的 HashiCorp Vault

今年的 AWS Summit Taiwan 2021 是線上的形式，早在前一個月前就先預錄好，但開始的時候就忘記要宣傳一下了... 結果是在找資料的時候發現其他人有提到：「AWS實作紀錄 #2：高可用性保管服務 (2021 AWS Summit Taiwan)」。

投影片與影片如果有興趣的人可以去 AWS 活動頁面上看，或者上面提到的那篇。

這次講的主題是想要在雲端上面搭建 Vault，但又不希望自己搞一堆 High Availability 的架構，最好是雲端服務本身就有提供... 而既然是在 AWS 的場子，主要都還是以 AWS 的服務來搭建。

在這次的設計裡，Vault 的資料是放在 DynamoDB 上，然後透過 KMS 管理加密用的，這兩個服務本身都有 High Availability，所以直接用就可以了。

接下來是跑 Vault 程式的部份，這部份得自己處理 High Availability 的架構，我是用兩台很小台的 EC2 instance (t4g.nano) 在跑，這邊也可以換成 ECS 或是 EKS 的 container。

接下來把這兩台 EC2 instance 掛起來的也都是 High Availability 服務：在 EC2 instance 前面用 ELB 擋住提供 HTTP API 服務，另外這邊即使是內部用，也可以上 HTTPS (透過 ACM 掛上 HTTPS 的憑證)。

在 ELB 上看到只有一台機器活著是正常的，因為兩台機器之間是 active-standby 架構，同時間只會有一台機器在運作，而 lock 的機制是 Vault 透過 DynamoDB 實做的，不需要另外處理。

其實裡面大多數的元件都可以抽換，像是 DynamoDB 也可以用其他的服務來當儲存層，馬上可以想到的是 RDS 的 MySQL 或是 PostgreSQL。

概念上不算困難，所以投影片上主要就是給設定檔，這樣方便大家抄，不用在自己摸指令摸半天...

當 credential 外洩時的處理方式...

昨天講到 Udacity 把 credential 放到 git repository 裡的方式 (參考「Udacity 管理 credential 的方式...」這篇)，結果就看到另外一篇講當外洩時降低傷害的文章：「Leak Mitigation Checklist」。

裡面講的方法沒什麼特別的 (倒是花了不少篇幅在介紹各家的 credential 要怎麼重生)，畢竟這是一份 checklist，只是要確保最低標準的步驟都應該要確認有做。

不過這兩篇放在一起看還蠻有趣的...

Udacity 管理 credential 的方式...

看到 Udacity 管 credential 的方式，可以用「我就是想把這些東西放到 Git 裡面管理啦」來解釋：「Three Simple Rules for Putting Secrets into Git」。

看了一下 Udacity 的架構，從 catalog-api.udacity.com 看起來應該是放在 AWS 的 us-west-2 上？那麼不考慮使用 AWS 的 KMS 是什麼？或是退一步來說，連自架的 Vault 也不考慮的原因又是什麼？下面的 response 好像沒什麼人提出問題... 在不知道前提的情境下，選擇這樣的方法其實有點怪，2012 年成立的公司有這麼重的包袱嗎？

先看看就好 XD

Netflix 用 CloudTrail 記錄找出 AWS key 外洩的小工具

在「aws-credential-compromise-detection – Detecting Credential Compromise in AWS」這邊看到可以抓漏的專案 Netflix-Skunkworks/aws-credential-compromise-detection。

透過分析 CloudTrail 記錄找出有哪些可疑的 AWS key 被外部使用，看起來預設值會過濾掉 Private IP range 以及 100.64.0.0/10 (設給給 CGNAT 使用的網段)。

不過 Netflix-Skunkworks 的定位是什麼啊，裡面好像有不少有趣的東西...

各種 credential 儲存的方式 (像是連到資料庫的密碼)

John Resig (現在在 Khan Academy) 在月初的時候發表了「Keeping Passwords in Source Control」討論要怎麼儲存 credential。

這不只是開發者的問題而已，這跟 code deploy 機制也很有關。目前沒有完美的方案，不同的解法都是在不同的環境與限制下而誕生出的產物。