實作三：用完就撤銷的資料庫憑證

**目標：**親手驗證密碼有生命週期，且資料庫真的限制存取範圍。

OpenBao 的 PostgreSQL secrets engine 依預先設定的 SQL 建立臨時登入角色。每位學員的角色只獲准讀自己的 schema，預設租約 60 秒、最長 120 秒。本課不顯示密碼，避免複製到筆記、截圖或 trace。

操作

1. 在「短效憑證」按「取得 60 秒憑證」。記錄 role 名稱、lease ID 與 TTL。
2. 立即按「以此憑證開新連線」，預期成功。
3. 按「嘗試讀其他學員 schema」，預期被資料庫拒絕。
4. 按「立即撤銷憑證」，再開新連線，預期失敗。
5. 重新發證，不撤銷，從收到發證回應起等待 66 秒後再開新連線，記錄實際等待秒數與結果。

驗收

交出同一份租約在「有效、撤銷、到期」三種狀態下的新連線結果。能說明 lease ID 和密碼不是同一個東西，以及為什麼不該把密碼記進追蹤。

容易誤解的地方

TTL 不是精確斷線倒數。 錄影初次測試曾在超過 60 秒後仍能建立新連線；核對 OpenBao 2.6.3 程式碼與 PostgreSQL rolvaliduntil，資料庫期限比 TTL 多約 5 秒緩衝。這是為避免資料庫帳密先於租約失效；OpenBao 的到期撤銷也涉及排程。本課改從發證回應起實際等待 66 秒再測，記錄結果，不把單次結果當作精確的撤銷延遲保證。版本原始碼

架構討論：若付款或敏感操作要求立即停止，應在應用授權層再次檢查，並設計緊急撤銷及連線池處理，不只依賴憑證 TTL。

租約到期不保證所有既有資料庫連線立即中斷。這取決於引擎撤銷語句、資料庫連線狀態與應用程式的連線池。本課每次測試都開新連線，不能把結果擴大解讀為所有長連線都會中止。

OpenBao 的 token 與它簽發的資料庫帳密也不同。前者授權呼叫 OpenBao，後者用於 PostgreSQL。正式系統還要處理最初的機器身分、續租、輪替與緊急停用。

參考：OpenBao PostgreSQL 引擎。Kubernetes Secrets Management 可補充概念，但其 Vault 範例不直接視為 OpenBao 的現行 API。