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 裡面手動刪除這些資料。
總之請大家別忘了在服務裡面加上 graceful shutdown 時同時也去撤銷 vault 裡面的 credential，免得原本採用 Vault 是要降低痛苦卻適得其反，讓痛苦太多，收穫太少。
結語
另外一個方面，當 vault 在 production 環境使用時，會有許多為了安全性而設計的麻煩事情，比如說當啟動 vault 時會需要使用 unseal key 把 vault 解封 (unseal) 才可以使用，所以比如說
CoreOS 自行重新開機更新 kernel 時，vault 服務就會停擺需要等管理者來 unseal 的狀況，所以架設時有許多狀況需要細部設定。
