December 2020 – Gea-Suan Lin's BLOG

Vault 裡 AppRole 的設計，以及怎麼解決 Secret Zero 問題

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 可以提供稽核記錄，把幾個比較明顯的問題解了不少...

Vultr 也推出 Kubernetes 服務 (Beta)

看到 Vultr 也打算要推出 Kubernetes 這個產品線了：「Announcing Vultr Kubernetes Engine!」。

這樣加上之前的 Linode 的 Linode Kubernetes Engine (LKE) 與 DigitalOcean 的 DigitalOcean Kubernetes (「DigitalOcean 也推出 Kubernetes 的服務」)，比較知名的幾家 VPS 都推出 K8S 的產品線了。

對於不是 cloud provider 的 VPS provider 來說，直接拿 K8S 整合可以建了一組 mini-AWS 的架構出來，而且因為軟體還算紅，既有的 ecosystem 也可以直接拉進來，不需要另外重新學。不過因為 K8S 發展很快，還是可以常常看到各種踩雷抱怨文... XD

對於使用者來說，如果有一定的量與技術能力，加上想要省錢的話，用這些 VPS 提供的 K8S 服務看起來是個不錯的選擇。

應該找些時間更新之前自己摸索的那些東西了 (之前整理在「Kubernetes」這邊)，理解底層會怎麼弄的對於在分析問題時還是蠻重要的 (i.e. 通靈)，記得兩年前如果自己要弄 K8S master HA 還是 beta 功能...

vim-polyglot 把預設的 tabstop 改成 2

發現 Vim 開 Makefile 類的檔案 (包括 GNUmakefile) 的 tab 都變成 2 格，交叉測了一下發現是 vim-polyglot 造成的：「Polyglot is wrongly setting tabstop to 2 on several file types #648」。

目前先用作者提到的方式 let g:polyglot_disabled = ["autoindent"] 解 (在首頁也有提到這個)。

目前看起來正常一些了...

IdenTrust 願意再幫 Let's Encrypt 交叉簽三年

先前在「Let's Encrypt 在 Android 平台上遇到的問題」這邊提到了 IdenTrust 幫 Let's Encrypt 交叉簽名的有效日會在 2021 年的八月底左右到期，而這會導致比較舊的 Android 平台因為沒有內建 ISRG Root X1 這個憑證，造成 Let's Encrypt 簽出來的憑證在這些舊的 Android 裝置上都認不出來。

文章出來過了一個多月後，剛剛看到 Let's Encrypt 發佈消息，IdenTrust 願意再交叉簽名三年：「Extending Android Device Compatibility for Let's Encrypt Certificates」，當時猜測發文是要讓 IdenTrust 表態，看起來目的達成了...

話說中間跑出來的「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」不知道後續會怎麼樣，之後可以看看 Certificate Transparency 的資料來看看到底有多少人用...

FreeBSD 要從 Subversion 換到 Git

在 #bsdchat 上面看到 FreeBSD 提供了 Git repository，翻了一下看起來是最近在切換，這邊有翻到慣例的 HEADS UP：「HEADS UP: FreeBSD changing from Subversion to Git this weekend」。

The FreeBSD project will be moving it's source repo from subversion to git starting this this weekend. The docs repo was moved 2 weeks ago. The ports repo will move at the end of March, 2021 due to timing issues.

大概是 2008 年先把 src tree 從 CVS 換到 Subversion 上：「FreeBSD src 部份由 CVS 轉換到 Subversion」。

然後 2012 年把 ports tree 換過去：「FreeBSD ports 將從 CVS 轉移到 Subversion 上...」。

雖然已經很久沒用 FreeBSD 了 (最近碰到最接近的系統應該是 pfSense)，但還是先恭喜他們總算要切換了，兩邊的能量差太多了...

AWS 淘汰 Amazon RDS (MySQL 5.5) 的計畫

AWS 規劃要淘汰 Amazon RDS (MySQL 5.5)，不過我是從 Percona 這邊看到...：「Amazon RDS for MySQL 5.5 EOL Date is Approaching – Act Now!」，找了一下官方的文件，在「Announcement: Amazon RDS for MySQL 5.5 End-of-Life date is approaching」這邊可以翻到。

如果硬要待在 MySQL 5.5 的話，目前看起來比較容易的解法應該是自己用 EC2 架，不過這樣的話 High Availability 的架構就頗麻煩了，用 ELB 可能是個方法...

話說回來，好久沒用 MySQL 5.5 了，這個版本記得是 InnoDB Plugin 整合進 MySQL 的第一個版本，先前應該是 MySQL 5.1 + InnoDB Plugin 的方式跑，我記得當時就是要 COMPRESSED 格式，算是 MySQL 當時蠻重大的進展...

手上還有在 5.5 上跑的人應該要自己安排時間換，儘量不要等到 AWS 硬升級的時候換，這樣炸掉的機會蠻高的...

找出非同溫層的書籍

前幾天在 Hacker News Daily 上看到有趣的服務：「Break the Bubble!」，這是由 A Book Like Foo 提供的服務，你輸入至少兩本你喜歡的書，然後他就丟一些非同溫層外的書籍出來...

我隨便丟了 1984 + TAOCP + CLRS 三本進去，推薦出來的書丟到 wikipedia 翻了一下，看起來的確都是平常不會想看的內容 XDDD

找時間問一下同事，看看這後面的演算法會怎麼玩...

AWS 推出 Amazon Location

AWS 推出了 Amazon Location：「Amazon Location – Add Maps and Location Awareness to Your Applications」，目前是 Preview 階段，但開放給所有人使用，而且不收費。

目前合作的圖資是 Esri 與 HERE Technologies：

You can choose between maps and map styles provided by Esri and by HERE Technologies, with the potential for more maps & more styles from these and other partners in the future.

先比較了一下 Amazon Location 在 map 這塊預定收費的價錢與 Mapbox pricing 這邊列出來的價錢，看起來兩邊的算法不太一樣，AWS 這邊是照 tile 數量算錢，Mapbox 則是算 load 次數算錢，看起來 AWS 這邊服務的在大量互動的情況下會比較貴 (會拉很多 tile)，但對於像是只是展示可能會便宜不少，像是 591 的那種用法。

其他的項目就先暫時懶的看了...

開放的區域是老面孔了，其實比較好奇為什麼這類服務不是一次把商業區全開：

Amazon Location is available in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo) Regions.

Bash Script 的好習慣

這篇給了一份 bash script 用的 tempalte，但更重要的反而是裡面提到的 best practice：「Minimal safe Bash script template」。

首先是不要寫 /bin/bash 這件事情，因為有些系統是沒有 /bin/bash 的，像是 FreeBSD。

如果程式是可以用 POSIX sh 語法的話，應該優先考慮 /bin/sh，如果用到非 POSIX 標準的語法的話，用 env 帶出來會少一些問題：

#!/usr/bin/env bash

再來是 fail 時就趕快停止，不要再往下執行，這點算是老生常談了，文章作者也有給一個範例說明：

set -Eeuo pipefail

再來另外一個還蠻有用的事情是攔下常見的 signal 處理「後事」：

trap cleanup SIGINT SIGTERM ERR EXIT

cleanup() {
  trap - SIGINT SIGTERM ERR EXIT
  # script cleanup here
}

其他的可以看一看，但未必要全盤收下...

AWS 推出 CloudShell

AWS 推出了 CloudShell，讓使用者可以繼承 IAM 的權限，在瀏覽器裡面用 command line 操作 AWS 資源：「AWS CloudShell – Command-Line Access to AWS Resources」。

使用方式很簡單，在 web console 上方的 icon 點下去就可以用了，只是第一次使用的時候會看到需要建立環境的訊息，會等比較久：

連進去後測了一下，看起來是跑一個 30GB Disk 與 4GB RAM 的 container 起來，/proc/cpuinfo 裡面可以看到是 Intel E5-2676 v3 的機器，以這個資訊來查，看起來可能是 m4 系列的機器。

網路的部份基本上對 internet 的 TCP 與 UDP 都可以通，但需要操作 raw socket 丟 ICMP 的 ping 與 mtr 就不會通了。

目前支援的區域只有這些，之後應該會陸陸續續再開放：

Regions – CloudShell is available today in the US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo) Regions, with the remaining regions on the near-term roadmap.

費用的部份，官方是說不需要另外的費用，只需要付出用到的 AWS 資源，但這邊沒給範例啊，到底是怎麼算的... 看了一圈 EC2、ECS、EKS 都沒有機器，應該是不會算到這邊？

Pricing – You can use up to 10 concurrent shells in each region at no charge. You only pay for other AWS resources you use with CloudShell to create and run your applications.

刷了一下的感覺是，對於已經習慣跳板機的人來說好像還好，尤其是 command line 已經用熟了，太習慣用 Ctrl-W 刪字串，而在瀏覽器裡面按下去就會直接出事的情況，還是有點難用...

比較明顯的好處應該是整合了 IAM 的權限，所以在 awscli 下的權限是一樣的，另外對於有些 web console 沒支援的操作可以用這個方法補強，而不需要自己弄機器出來跑。