https://christina04.hatenablog.com/entry/vault-login-golang
user passwd get token
https://www.vaultproject.io/docs/auth/userpass.html
setting token
https://www.vaultproject.io/docs/auth/token.html
今天找到一篇有分享經驗的文章 http://sueboy.blogspot.com/2019/01/vault.html
1、量大 Vault有機會掛
2、Vault的重啟 需要特定 5把金錀 3把同意 才能開啟，所以人要登入，不然就是要模擬操作 但模擬操作就失去意義
3、服務被更新重啟，又會發生2的情況
Vault就是簡單說就是管理 帳號、密碼、token、金錀，配合上ACL url ，有群組權限等功能
專案角度就是 啟動服務(docker)後，前端直接跟Vault做驗證登入，api url 呼叫是否有權限等，都是Vault會給出回應 能登入否 能存取否
更進階是token 金鑰 時效等等都可以設定，可用Vault的管理介面
當然 會面臨的第一個問題，怎麼建立account 、怎麼判斷(go server要去呼叫Vault，前端也可以呼叫Vault)，再來要多一個維護的系統，而且這個系統是最重要的，一掛，所以有的系統都登入不了
真的有比較好嗎？
1、要多一個系統做管理
2、要再多學一個系統操作、設定
3、真的掛了，運用本身沒掛，那………
4、有bug或是無法滿足特定條件權限時，怎麼辨
好處：
統一方式，除非將來Vault沒了，不然很多專案可以使用
https://medium.com/getamis/vault-dynamic-credentials-fd651d6c28a9
踩雷區
應同事要求特別寫一下 vault 的雷區，其實上面的 demo.js 最重要的地方就在於 graceful shutdown 時要把目前使用的 credential 給撤銷掉。
你可能會覺得這個 credential 放著也還好，反正時候到了就會過期，不會有太多影響。BUT!! 假如你跟我們一樣 dev 環境是每個 commit 都會 deploy，而且 credential 的過期日期設定的比較長，比如說一個月的話，每天十個 commit，kubernetes 裡面有十個 pod，每個 pod 可能會用到兩三個由 Vault 管理的動態憑證的話，你在資料庫或 IAM User 會膨脹的很快，很快地你就會發現這些為數眾多的 credentials 管理上會造成困難，甚至拖累整個開發環境。
像最近我突然知道原來 AWS IAM User 的預設上限是 5000 人…。
當你有很多 IAM User 的時候，雖然可以透過指令一次把所有由 Vault 管理的 IAM User 撤銷，但是就我們的經驗來說大量 revoke IAM User 的時候，vault 大多都會 timeout (也有可能是因為我們 dev 環境開的資源太少)，所以要執行很多次才能把所有使用者刪除，其中還有可能會因為資源太少導致 Vault crash 的狀況，在 production 的狀況 vault 重啟會需要 unseal，此時就會伴隨許多痛苦，甚至 vault 會被不停地打掛，到最後只好到 backend storage 跟 AWS console 裡面手動刪除這些資料。
https://blog.csdn.net/peterwanghao/article/details/83181932
