debug(ch2-lease): 加回 step2 + step3

Author: lonegunmanb

vault-tutorial/ch2-lease/step2/text.md

@@ -0,0 +1,60 @@
+# 第二步：max_lease_ttl 是续约的硬天花板
+
+文档 §3.2 的核心论断：
+
+> 任何一份机密，从签发那一刻起，最多只能活 `max_ttl`，
+> **无论续约多少次**。
+
+我们的 `readonly` 角色配置：`default_ttl=1m`，`max_ttl=5m`。
+这一步要把这条天花板撞出来。
+
+继续用第 1 步留下的 `$FULL_LEASE_ID`（如果新开的终端，重新算一遍）：
+
+```bash
+LEASE_ID=$(vault list -format=json sys/leases/lookup/database/creds/readonly | jq -r ".[0]")
+FULL_LEASE_ID="database/creds/readonly/$LEASE_ID"
+echo "$FULL_LEASE_ID"
+```
+
+申请一个**远超 max_ttl 的 increment**——比如 1 小时：
+
+```bash
+vault lease renew -increment=3600 "$FULL_LEASE_ID"
+```
+
+注意输出里的 `lease_duration` 字段：**它绝对不会是 3600，最多是 300（5 分钟）**，
+而且实际上会更小——具体值 = `issue_time + max_ttl - now`，也就是
+"距离这条租约的死刑日还剩多久"。
+
+这正是文档 §4.2 强调的：
+
+> The requested increment is completely advisory.
+
+再连续续两次：
+
+```bash
+sleep 5 && vault lease renew -increment=3600 "$FULL_LEASE_ID"
+sleep 5 && vault lease renew -increment=3600 "$FULL_LEASE_ID"
+```
+
+每次都申请 1 小时，每次返回的 `lease_duration` 都在**单调递减**。这就是
+天花板效应——再怎么续，也越不过最初签发时锁定的 5 分钟死刑日。
+
+为了直观看到死刑日，看一下完整的 lookup：
+
+```bash
+vault lease lookup "$FULL_LEASE_ID"
+```
+
+注意：
+
+- `issue_time` 是固定的（第 1 步签出来时刻）
+- `expire_time` 永远 ≤ `issue_time + 5m`
+- `last_renewal` 这次开始有值了
+
+等到这条租约过了 5 分钟自然死亡（或者直接进入第 3 步，反正它会自己消失），
+你就会看到对应的 Postgres 用户被 Vault 删掉。
+
+> **生产含义**：如果你的应用号称"我会一直续约所以可以拿一份永久凭据"——
+> 不可能。`max_lease_ttl` 是底线安全保障，强迫每一份机密都有一个**确定的
+> 失效时刻**。这样泄露后的爆炸半径就能被精确量化为「最多 max_ttl」。

vault-tutorial/ch2-lease/step3/text.md

@@ -0,0 +1,75 @@
+# 第三步：increment 是「从现在开始算」——可以主动缩短租约
+
+这一步演示文档 §4.1 那条最反直觉的论断：
+
+> The requested increment is **not** an increment at the end of the current
+> TTL; it is an increment from the current time.
+
+也就是说，**应用可以通过续约让自己手里的凭据提前过期**。
+
+签一份新凭据（前一份大概率已经被天花板撞死了）：
+
+```bash
+vault read database/creds/readonly
+LEASE_ID=$(vault list -format=json sys/leases/lookup/database/creds/readonly | jq -r ".[-1]")
+FULL_LEASE_ID="database/creds/readonly/$LEASE_ID"
+```
+
+看一眼当前 TTL（默认 60 秒）：
+
+```bash
+vault lease lookup "$FULL_LEASE_ID" | grep -E "ttl|expire"
+```
+
+现在做一件"看起来在续约、实际在缩短"的事——申请 increment=10：
+
+```bash
+vault lease renew -increment=10 "$FULL_LEASE_ID"
+```
+
+返回的 `lease_duration` 是 **10**，不是 60。再确认一下：
+
+```bash
+vault lease lookup "$FULL_LEASE_ID" | grep -E "ttl|expire"
+```
+
+`expire_time` 已经被往**前**挪到了"现在 + 10s"。再过 10 秒：
+
+```bash
+sleep 12 && vault lease lookup "$FULL_LEASE_ID" 2>&1 || echo "(已过期)"
+```
+
+应该看到 `invalid lease`——这条凭据已经被 Vault 自动 revoke 了，对应的
+Postgres 用户也消失了：
+
+```bash
+docker exec -i learn-postgres \
+  psql -U root -c "SELECT usename, valuntil FROM pg_user WHERE usename LIKE 'v-%';"
+```
+
+## 这个设计为什么有用？
+
+回想一下应用的真实场景：
+
+> 我的请求 handler 拿一份数据库凭据，**只会用 5 秒**——
+> 不需要默认的 1 分钟 TTL，更不需要 5 分钟的 max_ttl。
+
+按这个模型，应用应该：
+
+1. `vault read database/creds/readonly` 拿凭据；
+2. **立刻** `vault lease renew -increment=10`，把租约缩到 10 秒；
+3. 用完就完，不需要主动 revoke——10 秒后 Vault 自己回收。
+
+这样 Postgres 里同时存活的临时用户数量就被压到了**实际并发数 × 10 秒**，
+而不是 **实际并发数 × default_ttl**。一个大流量服务靠这种"自缩短"
+模式，能让目标系统侧的资源占用降一个数量级。
+
+> 文档 §4.1 把这种用法描述为：
+>
+> > makes it easy for users to reduce the length of leases if they don't
+> > actually need credentials for the full possible lease period, allowing
+> > those credentials to expire sooner and resources to be cleaned up earlier.
+
+`vault-basics` 第 4 步的 `vault lease renew "$FULL_LEASE_ID"` 命令没有
+带 `-increment`，那种用法是"按服务端默认顶满"。带上 `-increment=N` 才
+是真正用足这个 API 的能力。