Vault 裡 AppRole 的設計，以及怎麼解決 Secret Zero 問題
source link: https://blog.gslin.org/archives/2020/12/29/9908/vault-%e8%a3%a1-approle-%e7%9a%84%e8%a8%ad%e8%a8%88%ef%bc%8c%e4%bb%a5%e5%8f%8a%e6%80%8e%e9%ba%bc%e8%a7%a3%e6%b1%ba-secret-zero-%e5%95%8f%e9%a1%8c/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
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 可以提供稽核記錄，把幾個比較明顯的問題解了不少...
Related
Distributed Key-Value Database
這篇是因為在 PIXNET 內講了 n 次，決定寫成文字，至少之後新人進來可以說「就看這篇」，避免整套系統都需要重新講一次。 對了，補充一下，PIXNET 還是有缺人，參考「缺人找人」這篇的內容，如果有想問的細節，可以寫信問我。 資料庫 在 RDBMS 提供了很多而且很豐富的操作方式，但當資料量愈來愈大時，會遇到單台機器的網路頻寬有限以及空間有限。這時候一定得走向多台的架構。 Replication 最容易解決的情況是「讀取的 query 比寫入的 query 多」，可以用 database replication 解決，這也是 Web 1.0 網站常見的解法之一 (另外一種常見的解法是使用靜態檔案，或是 reverse proxy cache)，同步將資料複製到多台。 Memcached 接下來會發現當 slave 過多時會造成每台記憶體內重複 cache 相同的元素，也就是說，有二十台 slave，每台都有 SELECT * FROM `user` WHERE `name` = 'gslin' 的結果其實很浪費資源。不過這個問題可以用 memcached 或是 hash selection 解決。 Sharding 在…
July 25, 2009
In "Computer"
在 AWS 上跑 Consul 與 Vault 的介紹
從 HashiCorp 這邊看到在 AWS 上跑 Consul 與 Vault 的介紹文章：「Consul and Vault on AWS: Quick Start Guides」。 Consul 負責 service discovery 與 health check (還有簡單的 key-value 功能)；Vault 則負責管理各種 secret (像是資料庫的帳號密碼之類的資訊)。 這些資料分別可以在「HashiCorp Consul on AWS」與「HashiCorp Vault on AWS」看到，打開 PDF 後可以發現是 AWS 與 HashiCorp 的人合作生出來的文件，要在上面實作的人可以看一看，應該是可以少走冤枉路...
December 4, 2016
In "AWS"
Ethereum Smart Contracts 裡的 PRNG
現代密碼學的安全性有很大一塊是基於亂數產生器 (RNG) 非常難被預測。如果這個前提不成立的話，利用亂數產生器產生出來的各種資訊都會被預測出來 (尤其是 Private Key)。 但真正的 RNG 需要靠硬體支援，而且產生速度很慢，一般都會使用 PRNG (Pseudorandom number generator) 產生。也就是「看起來」很亂的亂數產生器。 PRNG 通常是指在統計學上通過許多測試，像是在多種測試都是 Discrete uniform distribution，不需要防止有惡意人，可以從產生出的 PRNG 的值而推導出後續結果的用途。 在「Predicting Random Numbers in Ethereum Smart Contracts」這篇裡面，作者列出了一堆實做 Ethereum Smart Contracts 卻誤用 PRNG 的行為。 文章裡提到的問題都是因為 PRNG 拿著可被預測的資訊當作 entropy source (e.g. seed)，而且提出來的範例都是拿 block 本身或衍生的資訊 (像是 block 的 hash) 來用： PRNGs using…
February 4, 2018
In "Computer"
Author Gea-Suan LinPosted on December 29, 2020Categories Computer, Murmuring, Network, Security, Service, SoftwareTags approle, authentication, hashicorp, id, role, role_id, secret, secret_id, vault, zeroLeave a Reply Cancel reply
Your email address will not be published. Required fields are marked *
Comment
Name *
Email *
Website
Notify me of follow-up comments by email.
Notify me of new posts by email.
Post navigation
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK