還記得在上一篇中,我們提到了 TTL 及 Lease(租約)的基本概念,這些其實都跟我們接下來要講的 Credential Lifecycle 有關。
甚麼時候該讓 Credential 失去效力?
甚麼時候該 renew Credential 效力?
甚麼時候該更改 Credential ?
Vault 的核心思想之一,就是讓 Secret 不只是「被安全地存放」,還能進一步被管理其生命週期。
那我們該如何應用 Lifecycle 的概念至真實場景?
我們試著用更白話的方式來解釋。
TTL(Time To Live)代表 Credential 或 Lease 的有效時間。
舉個例子來說,Application 可以使用這組帳號連線 Database,但這組 Credential 並不是永久有效。
我們可以透過Lease上的資訊,知道這份租約的效期還有多久。
如果 Application 執行時間比原本的 TTL 更久,就可能需要延長 Lease。
也就是說當某個Production service在run時再過半小時就要達到TTL,便可以透過Renew機制在合理範圍內延長期效期。
vault lease renew <lease_id>
或是針對Credential iteself:vault lease renew database/creds/my-role/xxxx
倘若我們發現某組Credential發生leaking,便需要當機立斷讓它失效。
vault lease revoke <lease_id>
vault lease revoke database/creds/my-role/xxxx
失效的意義在於revoke後不能再使用該token進行驗證,但不代表著它被刪除。
從官方文件中,我們可以知道其還支援了更細的 Token hierachy 操作。
若以token A 建立 token B 跟 token C,使用mode=path revoke A後會連帶 revoke B 跟 C (傳遞revocation鏈)
-mode (string: "") - Type of revocation to perform. If unspecified, Vault will revoke the token and all of the token's children. If "orphan", Vault will revoke only the token, leaving the children as orphans. If "path", tokens created from the given authentication path prefix are deleted along with their children.
Rotation 的目的之一,是避免同一組長期 Credential 永久存在。
假設公司原本有固定 DB 帳號:
username = app_user
password = OldPassword123
我們需要讓 Vault 知道怎麼連 Database,然後建立一個 Static Role,把 Vault Role 對應到既有 DB User。
也就是說,我們需要讓 Vault 本身需要一組具有適當 DB 權限的 Credential,並在一定期間後透過該帳號讓 Vault 對 B 進行 user account 的 rotation。
所以並不是 Vault 本身可以 Access DB,而是透過儲存於 Vault 中的a dmin db account 來存取資料庫進行管理者等級的操作。