幹壞事是進步最大的原動力
昨天在「AWS User Group Taiwan Meetup 2022-03 線上 / 下小聚」這邊分享的主題，在講如何在 AWS 上弄出一個高可靠性的 Vault 服務。
投影片在 https://bit.ly/3igUbgh 這邊可以抓到，我另外傳到 Speaker Deck 上面了：(好久沒用這個網站了？)
其實這類架構的設計有點像是 AWS 的 Solution Architect 在做的事情，如果一般的客戶開出類似的需求，應該也是會設計出類似的東西...
另外畢竟是在 AWS 的會議室裡面講，有些東西還是會避免提到，但裡面有很多概念是可以互換的，像是 Microsoft Azure 或是 GCP 上面都有可以抽換的服務，Vault 也都有支援。
以前 HashiCorp 家的軟體大多都是自己下載 binary 後放到 /usr/bin 或是 /usr/local/bin 下使用，剛剛翻了一下 Nomad 與 Vault，看起來都支援 APT repository 了：「https://apt.releases.hashicorp.com」；另外也有 RPM repository：「https://rpm.releases.hashicorp.com」。
這樣下個禮拜分享會的投影片也要改一改了...
今年的 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。
概念上不算困難，所以投影片上主要就是給設定檔，這樣方便大家抄，不用在自己摸指令摸半天...
HashiCorp 的東西都還蠻有品質的 (相較於其他的類似方案)，其中有一個觀察到的特性是，如果他門把版本維持在 0.x，代表他們自己對軟體的品質與成熟度都不算滿意。
而 Terraform 算是他們家對於基礎建設資源管理所提出的方案 (尤其是雲端時代的資源)，不過之前最頭痛的，每次升級就會發現有些基本的概念會被改掉，所以不是改改關鍵字就可以解決。
這次 Terraform 推出 1.0 版，代表了他們認為產品有一定的成熟度：「Announcing HashiCorp Terraform 1.0 General Availability」，另外在 GitHub 上面的「Release v1.0.0 · hashicorp/terraform」也可以看到：
Terraform v1.0 is an unusual release in that its primary focus is on stability, and it represents the culmination of several years of work in previous major releases to make sure that the Terraform language and internal architecture will be a suitable foundation for forthcoming additions that will remain backward compatible.
另外也可以從他們對相容性的宣示「Terraform v1.0 Compatibility Promises」看出來他們覺得架構上成熟了：
For all future minor releases with major version 1, we intend to preserve backward compatibility as described in detail in the Terraform v1.0 Compatibility Promises. The later Terraform v1.1.0 will, therefore, be the first minor release with new features that we will implement with consideration of those promises.
總算是開始進入會考慮 backward compatibility 的週期了...
Vault 是 HashiCorp 拿來管理各種敏感資訊的軟體，像是 API token 或是資料庫的帳號密碼。把這些資訊集中控管後就不需要把這些資訊放進 Git (超爽的？)，而是在需要的時候由應用程式呼叫 Vault 取得。
而 Vault 的設計裡面要求應用程式需要「認證」後才能取得，結果這個「認證」又是一組敏感資訊，這就是 Secret Zero 問題，屬於雞蛋問題的一種。
找了一輪發現 HashiCorp 自家的說明解釋的最清楚，不過這篇是放在 blog 上的文章：「Tackling the Vault Secret Zero Problem by AppRole Authentication」。
Vault 在解決 Secret Zero 的方法是使用 AppRole，這邊的認證包括了 role_id 與 secret_id 的設計。比較特別的是一組 role_id 可以有多組 secret_id 對應。
在 AppRole 這樣的設計下，權限會綁在 role_id 上，而 secret_id 則可以在部屬時動態產生，像是官方提到的 Terraform 與 Chef，或是依照組織裡面使用的管理工具：
這樣就可以透過 role_id 管理權限，但不用在 Git 裡面寫死 Secret Zero 資訊，而且每台機器都有自己的 secret_id 可以提供稽核記錄，把幾個比較明顯的問題解了不少...
HashiCorp 推出了兩個新的產品。
第一個是 Boundary，這個產品看起來還很早期，但看起來想要實做 BeyondCorp 的一些想法 (可以參考之前寫的「Google 推的 BeyondCorp」)：「Announcing HashiCorp Boundary」，這在 Hacker News 上有討論串，而且 HashiCorp 的老大 Mitchell Hashimoto 也有出來回答一些問題：「HashiCorp Boundary (hashicorp.com)」。
這個產品讓他慢慢發展起來應該會是不錯的 open-source implementation，不過傳統的 castle 在小一點的場合也還算夠用...
另外一個是 Waypoint，看起來是個 CI/CD 類的產品：「Announcing HashiCorp Waypoint」，在 Hacker News 上也有討論串，而且同樣的 Mitchell Hashimoto 也有在裡面回覆一些東西：「Waypoint: Build, deploy, and release applications across any platform (hashicorp.com)」。
我自己看了一下設定的方式以及一些畫面，然後再回頭看 Hacker News 上的討論，以目前得到的資訊來看，這個產品似乎沒有很明顯解決到痛點，也許就是補產品線...
Cloudflare 推出了 Cron Triggers，有兩篇說明：「Introducing Cron Triggers for Cloudflare Workers」、「Making Time for Cron Triggers: A Look Inside」。
底層架構上是用 Nomad 做的：
To consume the schedules and actually trigger the Worker, we built a new service in Rust and deployed to our edge using HashiCorp Nomad. Nomad ensures that the schedule runner remains running in the edge node and can move it between machines as necessary.
多了定時跑程式的能力後，整個 serverless 平台的拼圖又多了一塊，現在看起來應該是要發展 storage 與 database-like 系統...
HashiCorp 宣佈了 HashiCorp Cloud Platform 這個產品：「Announcing the HashiCorp Cloud Platform」。
不是自己弄機房建 cloud，而是在既有的 cloud 上提供服務，就不需要自己架了：
HashiCorp Cloud Platform (HCP) is a fully managed platform offering HashiCorp products as a service to automate infrastructure on any cloud.
HCP Consul on AWS is now available in private beta. HCP Vault coming soon.
照目前公開的資料，第一個支援的是 AWS 上的 Consul，下一個是 Vault，然後目前推出的是 early access，看起來是走 pay-as-you-go 的模式收費：
Push-button deployments
Production-grade infrastructure, built-in security, and pay-as-you-go pricing accelerate cloud adoption.
有點像是 Confluent 對 Kafka 的玩法，不過 Kafka 光是架設就難搞很多，有他的市場在，另外 Confluent 走的是報價模式，需要找業務提供報價...
HashiCorp 這邊架設簡單不少，不知道玩不玩的起來...
GitHub 藉著 open source 函式庫，說明了目前還在 beta 的 GitHub Actions 是什麼：「An open source parser for GitHub Actions」。
GitHub Actions 是 GitHub 規劃將自動化設定包裝成設定檔的服務，以往是透過 GitHub 網站上設定，現在則是把這些設定放到 git repository 內。
重點在於 Actions 其實是透過 HCL (HashiCorp Configuration Language) 語法定義：
All Actions workflow files are valid HCL, but not all HCL files are valid workflows.
看到「HashiCorp Vault 1.0」這則消息，Vault 要出 1.0 不是什麼新聞，重點是他把跟 Cloud Auto Unseal 的功能放出來了：
In Vault 1.0, we are open sourcing Cloud Auto Unseal, allowing for all users of Vault to leverage cloud services such as AWS KMS, Azure Key Vault, and GCP CKMS to manage the unseal process for Vault.
可以看在 AWS 上的作法：「Auto-unseal using AWS KMS」。
這樣在雲上的服務可以再降低風險...