密钥 · XB 现场笔记

Kubernetes Secret 需要明确的访问边界

Sat, 21 Aug 2027 00:00:00 +0000

Kubernetes Secret 是用于保存工作负载所需机密值的 API 对象，提供专门的类型、消费路径和访问控制目标。但它不会让所有其他参与者都无法读取内容。设计边界时，需要同时考虑谁能取回对象、谁能创建消费者、谁能查看消费者输出，以及谁能管理运行它们的节点。仅区分配置对象与秘密对象，还不足以完成权限设计。

编码与保护处于不同层次

在 JSON API 表示中，Secret 的 data 使用 base64；stringData 则便于在写入时提交字符串。Base64 无需密钥就能还原，并不是加密。这种表示也不能证明某个具体集群怎样保护底层存储。Kubernetes 文档说明，若未配置相应加密，秘密数据默认不在存储层加密。应核对实际 API 服务器和存储设置，不能看到编码文字就推断保密措施已经生效。

存储加密同样不会阻止获得授权的 API 读取者拿到数据。RBAC 中的 get、list 和 watch 权限都可能暴露 Secret 内容，广泛的列表权限并不只是允许查看对象名称。备份和诊断输出也需要保护。正常应用最终仍要获得可用值，因此，一旦有权消费数据的程序被控制，攻击者就已经进入这份数据的信任边界，不能靠编码再次隔离它。

Secret 适合小规模值，单对象有一 MiB 限制。应只挂载需要的键，并只交付给真正需要它的容器。文件模式可以缩小工作负载内部的读取范围，却不能替代 API 授权或对创建工作负载权限的控制。环境变量注入也有暴露范围和生命周期方面的取舍，应根据应用需求选择，不能默认它一定比文件更安全。

坏掉的样子

禁止直接 get Secret，不一定禁止间接取得内容。主体如果可以在命名空间创建 Pod，通常就能在自己提交的规范中指定一个 Secret 卷，由 kubelet 把数据交给该工作负载。创建相应控制器的权限也可能产生类似效果。因此，除了直接读取数据的规则，还必须一起审查创建工作负载的权限及适用的准入限制，否则边界会漏掉实际消费路径。

把全部键挂进去，会扩大进程能够读取的内容集合。通过 volume items 只选一个键，可以限制这一次投射，但有更大创建权限的主体仍可能提交另一份投射定义。不能把一份范围较小的清单，误当成编写清单的人本身也受到同等范围限制。预期消费者是谁，以及谁能定义消费者，是需要分别处理的两个权限问题。

轮换也不只是修改 API 对象。数据交付、应用重新加载、凭据签发和旧值撤销都有各自时序。环境快照与 subPath 挂载不会像普通投射那样自动刷新；文件更新也不会强迫应用丢弃已经缓存的旧值。只有把签发系统与消费者一起验证，才能判断旧凭据是否确实不再被接受，不能仅以对象更新时间作为轮换完成证据。

快速验证

以下实验及观察结果沿用原文记录。本次审阅没有重新执行 Kubernetes 集成实验；文中的成功结果属于历史记录，不代表本轮取得了新的运行证据。

准备可丢弃的 Kubernetes 集群，并使用有测试 impersonation 权限的管理员连接，确保节点已有 python:3.11-slim-bookworm 镜像。保存为 secret-access.py，执行 python3 secret-access.py KUBECONFIG_PATH CONTEXT，明确指定专用配置和上下文。实测版本为 Kubernetes 1.34.11。这里全部数值都是明确的合成示例，输出只报告检查结果，不打印存储内容。

import json
import subprocess
import sys
import time
from uuid import uuid4

assert len(sys.argv) == 3, 'usage: python3 example.py DISPOSABLE_KUBECONFIG CONTEXT'
base = ['kubectl', '--kubeconfig', sys.argv[1], '--context', sys.argv[2], '--request-timeout=30s']
image = 'python:3.11-slim-bookworm'


def k(*args, payload=None, expected=0):
 result = subprocess.run(base + list(args), input=json.dumps(payload) if payload is not None else None,
 capture_output=True, text=True, timeout=150)
 if expected is not None:
 assert result.returncode == expected, result.stderr
 return result


def obj(namespace, kind, name=None, selector=None):
 args = ['get', kind, '-n', namespace, '-o', 'json']
 if name:
 args.append(name)
 if selector:
 args += ['-l', selector]
 return json.loads(k(*args).stdout)


def apply(namespace, data):
 return k('apply', '-n', namespace, '-f', '-', payload=data)


def wait_for(read, ready, seconds=120):
 until = time.monotonic() + seconds
 while time.monotonic() < until:
 value = read()
 if ready(value):
 return value
 time.sleep(0.5)
 raise AssertionError('expected Kubernetes condition did not arrive')


def pod_ready(pod):
 return any(c['type'] == 'Ready' and c['status'] == 'True'
 for c in pod.get('status', {}).get('conditions', []))


def spec(script='import time; time.sleep(600)'):
 return {'automountServiceAccountToken': False, 'terminationGracePeriodSeconds': 1,
 'containers': [{'name': 'app', 'image': image, 'imagePullPolicy': 'IfNotPresent',
 'command': ['python3', '-c', script],
 'resources': {'requests': {'cpu': '10m', 'memory': '24Mi'},
 'limits': {'cpu': '200m', 'memory': '96Mi'}}}]}

import base64
namespace = 'notes-secrets-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 demo = 'DEMO_ONLY_NOT_A_CREDENTIAL'
 k('create', '-n', namespace, '-f', '-', payload={'apiVersion': 'v1', 'kind': 'Secret', 'metadata': {'name': 'example'},
 'type': 'Opaque', 'stringData': {'needed': demo, 'unused': 'UNUSED_DEMO'}})
 stored = obj(namespace, 'secret', 'example')
 assert base64.b64decode(stored['data']['needed']).decode() == demo
 apply(namespace, {'apiVersion': 'v1', 'kind': 'ServiceAccount', 'metadata': {'name': 'creator'},
 'automountServiceAccountToken': False})
 apply(namespace, {'apiVersion': 'rbac.authorization.k8s.io/v1', 'kind': 'Role',
 'metadata': {'name': 'pod-creator'},
 'rules': [{'apiGroups': [''], 'resources': ['pods'], 'verbs': ['create', 'get']},
 {'apiGroups': [''], 'resources': ['pods/log'], 'verbs': ['get']}]})
 apply(namespace, {'apiVersion': 'rbac.authorization.k8s.io/v1', 'kind': 'RoleBinding',
 'metadata': {'name': 'pod-creator'},
 'subjects': [{'kind': 'ServiceAccount', 'name': 'creator', 'namespace': namespace}],
 'roleRef': {'apiGroup': 'rbac.authorization.k8s.io', 'kind': 'Role', 'name': 'pod-creator'}})
 identity = 'system:serviceaccount:' + namespace + ':creator'
 denied = k('--as', identity, 'get', 'secret', 'example', '-n', namespace, expected=None)
 assert denied.returncode != 0 and 'Forbidden' in denied.stderr
 probe = "from pathlib import Path\nimport json,time\nroot=Path('/example')\nprint(json.dumps({'synthetic_value_matches':(root/'one').read_text()=='DEMO_ONLY_NOT_A_CREDENTIAL',\n 'unused_key_absent':not (root/'unused').exists(),\n 'service_account_token_absent':not Path('/var/run/secrets/kubernetes.io/serviceaccount/token').exists()}),flush=True)\ntime.sleep(600)"
 podspec = spec(probe)
 podspec['serviceAccountName'] = 'creator'
 podspec['volumes'] = [{'name': 'example', 'secret': {'secretName': 'example',
 'items': [{'key': 'needed', 'path': 'one'}], 'defaultMode': 0o400}}]
 podspec['containers'][0]['volumeMounts'] = [{'name': 'example', 'mountPath': '/example', 'readOnly': True}]
 definition = {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': 'reader', 'namespace': namespace},
 'spec': podspec}
 k('--as', identity, 'create', '-f', '-', payload=definition)
 wait_for(lambda: obj(namespace, 'pod', 'reader'), pod_ready)
 output = wait_for(lambda: k('--as', identity, 'logs', '-n', namespace, 'reader').stdout.strip(), bool)
 observed = json.loads(output)
 assert all(observed.values())
 print(json.dumps({'api_base64_decodes_to_synthetic_value': True,
 'direct_secret_get_forbidden': True, 'same_identity_can_create_consuming_pod': True,
 'mount_observation': observed, 'etcd_encryption_tested': False}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

程序创建包含两个演示键的 Secret，确认 API 中的 base64 可以还原成给定的合成文字。然后为服务账号绑定一个角色，允许创建 Pod 和读取 Pod 日志，却不给读取 Secret 的权限。管理员以这个账号身份发出的直接读取请求会返回 Forbidden，因此这一步实际验证了对应的 API 授权拒绝。

同一个被模拟的主体接着创建 Pod，只投射需要的键。由它指定的工作程序确认：读到预期演示值，未需要的键没有出现，也不存在自动挂载的服务账号令牌。该主体再通过获准的日志接口读取这些布尔结果。原文报告全部检查通过，展示了直接请求被拒绝之后，工作负载路径仍然能够取得指定内容，而不是仅从权限配置进行猜测。

命名空间最后被删除。本实验没有使用真实凭据或实际签发的服务账号令牌，也没有测试底层存储加密和轮换流程。它建立的是授权与投射行为的证据，不是一套完整秘密管理系统。在称某份数据已经严格限定范围之前，应同时评估直接读取者，以及能够创建或修改读取者的主体。

来源

Kubernetes: Secrets，API 表示、消费方式和访问含义，已核验 2026-10-15。
Kubernetes: Good practices for Secrets，加密、最小权限与工作负载访问，已核验 2026-10-15。
Kubernetes: RBAC authorization，资源操作、角色绑定和命名空间范围，已核验 2026-10-15。

ssh-agent 在会话期间替你记住已解密的密钥

Sat, 27 Feb 2027 00:00:00 +0000

SSH 代理为公钥认证提供签名操作。对于普通软件密钥，加载加密私钥时会解锁相关材料，此后代理便可以使用它，不必每次连接都重新询问文件口令。正常代理协议向客户端返回公钥身份和签名，而不是导出私钥。硬件支持的身份有所不同：私钥可以一直保留在认证器里，并要求触摸或用户验证，不能把所有代理身份都描述成完整私钥必然存放在代理内存中。

套接字提供的是服务访问能力

OpenSSH 通常通过 SSH_AUTH_SOCK 查找代理，但客户端配置中的 IdentityAgent 可以选择另一个套接字，也可以关闭代理使用。知道路径并不等于有连接权限。套接字和父目录的权限都重要；root 以及与用户同身份运行的其他进程，则是需要考虑的威胁。环境变量本身不能代替操作系统隔离，隐藏路径也不是可靠的保护边界。

能够访问代理，并不保证每个签名请求都会成功。密钥约束、确认要求、硬件在场和协议限制都可能拒绝请求。即使签名成功，远端服务器也不必接受这把密钥或授予权限。因此，本地签名能力与服务端授权决定应分开观察。诊断“代理里有钥匙但登录失败”时，不能只停留在身份列表这一层。

同时限制身份与委托

ssh-add 加载身份，并在需要时询问文件口令。但 ssh 的 AddKeysToAgent 等配置路径也能加载身份，不能说只有 ssh-add 才可能解锁。代理避免反复读取加密私钥文件，却不保证交换空间、转储、备份或其他进程中绝不存在私钥材料。操作系统与密钥存储策略仍然需要独立审阅，代理不是整台机器的保密证明。

-t 为添加的身份设置存活期限。到期后身份会被移除，这个参数不只是提醒；没有期限时，普通已加载身份可能一直留到显式删除或代理退出。移走、删除或者替换磁盘文件，并不会自动替换代理里已经加载的副本。轮换时应检查实际使用的指纹，而不是只确认文件名已经改变。

-c 通过 ssh-askpass 要求确认。决定是否批准的是辅助程序是否成功退出，而不是远端主机有没有终端。需要验证本地确认机制确实能工作，并拒绝意外请求。确认可以减少无人值守的使用，但仍需理解提示所代表的主机和操作，不能看到弹窗就习惯性通过，也不能把没有远端终端当作必然拒绝的证据。

OpenSSH 8.9 引入的目的地约束使用主机密钥进一步限制允许的认证路径。经过转发时，路径上的客户端需要支持相关协议；已知主机信息也必须正确识别目标。这不是靠域名文字就能独立工作的防火墙。依赖约束前应验证版本和兼容性，保持 OpenSSH 更新，并理解主机密钥变化如何影响允许的路径。

坏掉的样子

代理转发允许远端在转发通道存在期间中继签名请求。那里的管理员或被入侵进程可能使用这份能力，而不需要提取私钥。没有必要时应避免转发，并查看客户端最终生效的配置；命令行没有 -A，不足以证明配置文件没有开启它。风险在于签名委托，不在于私钥文件一定已经复制到远端。

从代理删除身份，并不会撤销已经被复制的私钥、删除服务器 authorized_keys 中的条目，也不保证关闭已建立的 SSH 会话。反过来，服务端撤销授权可能阻止新登录，即使代理仍保存这把钥匙。恢复计划应分别处理受影响的副本、授权记录和活动会话，而不是把其中一个动作误当成全部撤销。

现代 OpenSSH 代理还限制远端请求加载提供方，以及部分 FIDO 签名用途，以减少把转发认证器用于 SSH 之外的特定风险。这些保护不是公开套接字或随意放宽选项的理由。不同版本和平台集成的默认值、套接字位置可能不同；排查时应阅读当前实现的文档，不能把某次输出的路径和权限数字当成永远成立的协议常量。

快速验证

保存为 agent_config.py，在安装了 OpenSSH 的环境执行 python3 agent_config.py。实验创建临时配置，再通过 ssh -G 求出最终配置，不启动代理、不读取私钥、不建立连接，也不修改现有代理。合成环境变量里的套接字与显式配置刻意不同，而且两条路径都不需要存在，因此不会碰到真实认证服务。

import os
from pathlib import Path
import subprocess
import tempfile

with tempfile.TemporaryDirectory(prefix='agent-config-') as directory:
 work = Path(directory)
 alternate = str(work / 'alternate.sock')
 config = work / 'config'
 config.write_text(f'''Host chosen-agent
 HostName example.invalid
 IdentityAgent {alternate}
Host no-agent
 HostName example.invalid
 IdentityAgent none
''')
 env = {'PATH': os.defpath, 'SSH_AUTH_SOCK': str(work / 'environment.sock')}
 for host, expected in [('chosen-agent', alternate), ('no-agent', 'none')]:
 result = subprocess.run(['ssh', '-G', '-F', str(config), host],
 env=env, cwd=work, text=True, capture_output=True, check=True)
 fields = dict(line.split(' ', 1) for line in result.stdout.splitlines())
 if fields.get('identityagent') != expected:
 raise RuntimeError('unexpected IdentityAgent')
 print(host, 'identityagent=', fields['identityagent'])
 if (work / 'alternate.sock').exists() or (work / 'environment.sock').exists():
 raise RuntimeError('the fixture must not create an agent socket')
 print('PASS: explicit socket overrides environment; none disables agent use')

第一条结果选择显式配置的替代套接字，即使 SSH_AUTH_SOCK 指向别处；第二条选择 none。PASS 只确认这些配置规则。ssh -G 不验证套接字可达性、签名、到期、确认或远端登录。IdentityAgent none 关闭的是该次调用的代理使用，并不关闭文件密钥或其他认证机制，不能据此声称这个连接绝不可能认证成功。

若需要验证加载、存活期和确认，应另开得到授权的测试会话，并使用可丢弃的身份。不要为了重现文章，就对日常共用代理执行 ssh-add -D：它会删除全部已加载身份，可能中断其他工作。应把观察配置的实验，与改变凭据或真实会话的操作清楚分开，依据具体测试目标逐项取得证据。

来源

OpenBSD: ssh-agent，签名服务、套接字访问、提供方和 FIDO 限制，已核验 2026-10-15。
OpenBSD: ssh-add，存活期、确认、删除与目的地约束，已核验 2026-10-15。
OpenBSD: ssh_config，IdentityAgent、AddKeysToAgent 与转发配置，已核验 2026-10-15。
OpenSSH: agent restriction，主机密钥绑定与转发兼容性，已核验 2026-10-15。

凭据到期必须由验证方执行

Sun, 27 Sep 2026 00:00:00 +0000

只有负责决定是否允许访问的系统检查了适用截止时间，凭据才真的会到期。在资产清单里写一个日期，不会自动改变数据库或接口接受什么。较短有效期可以压缩被盗凭据继续建立新访问的时间窗口，但具体效果取决于认证机制，以及此前已经建立的会话、签发的其他凭据如何处理。秘密不是因为自身附带一行日期，就能独立让所有访问失效。

坏掉的样子

到期不会撤销已经发生的行为。复制出去的数据仍在外面，截止时间之前建立的会话也可能继续工作。攻击者还可能在原本有效的权限下建立另一条访问路径。因此，有效期只是限制后续使用的一种手段，还要结合权限范围、撤销机制、会话管理和对实际影响的调查。它并不能为一次泄漏造成的全部损失设定通用上限，也不能把过去的访问自动变成没有发生过。

PostgreSQL 的 VALID UNTIL 控制角色密码的有效时间，不控制角色是否存在，也不覆盖所有认证方式。使用非密码方式建立连接，就不会获得同样的截止检查。如果通过本地信任规则来测试密码到期，便可能误以为到期功能失效。判断结果之前，应先确认客户端实际命中了哪条认证路径，不能只看两次连接用了同一个用户名。

轮换与续期是两个不同变化。在 PostgreSQL 中，仅修改 PASSWORD 会保留 VALID UNTIL，仅修改 VALID UNTIL 也会保留原密码。更新流程如果只修改其中一项，可能导致应用依然无法重新连接，也可能让原值继续有效。一个连接池里的旧连接查询成功，不足以证明新凭据能够完成新的认证，因为它可能根本没有重新交出密码接受检查。

快速验证

准备隔离的 Linux 实验环境，让 PostgreSQL 18 程序位于 PATH 中，以非 root 用户运行，并确认回环端口 55477 未被使用。将下列内容保存为脚本，用 sh 执行。它初始化一次性数据库集群，只使用明确虚构的密码，TCP 仅监听回环地址，退出时删除临时目录。本地信任认证只为展示另一条认证路径而启用，不应照搬到真实服务：

#!/bin/sh
set -eu
lab_root=$(mktemp -d /tmp/credential-expiry.XXXXXX)
cleanup() {
 if test -f "$lab_root/data/postmaster.pid"; then
 pg_ctl -D "$lab_root/data" -m immediate -w stop >/dev/null
 fi
 rm -rf "$lab_root"
}
trap cleanup EXIT
initdb -D "$lab_root/data" --locale=C --auth-local=trust --auth-host=scram-sha-256 >/dev/null
pg_ctl -D "$lab_root/data" -l "$lab_root/server.log" \
 -o "-k $lab_root -p 55477 -c listen_addresses=127.0.0.1" -w start >/dev/null
admin() {
 psql -X -qAt -v ON_ERROR_STOP=1 -h "$lab_root" -p 55477 -d postgres "$@"
}
# Both passwords below are invented, disposable lab fixtures.
admin <<'SQL'
SET password_encryption='scram-sha-256';
CREATE ROLE article_expiry LOGIN PASSWORD 'LAB-ONLY-OLD-PASSWORD';
SQL
mkfifo "$lab_root/input"
PGPASSWORD=LAB-ONLY-OLD-PASSWORD psql -X -qAt -v ON_ERROR_STOP=1 \
 -h 127.0.0.1 -p 55477 -U article_expiry -d postgres \
 <"$lab_root/input" >"$lab_root/held.out" 2>"$lab_root/held.err" &
held_pid=$!
exec 3>"$lab_root/input"
printf "SELECT 'ready';\n" >&3
attempt=0
until grep -qx ready "$lab_root/held.out"; do
 attempt=$((attempt + 1))
 test "$attempt" -lt 100
 sleep 0.05
done
admin <<'SQL'
SELECT format('ALTER ROLE article_expiry VALID UNTIL %L',
 clock_timestamp()+interval '1 second') \gexec
SELECT pg_sleep(1.2);
SELECT 'deadline passed='||(rolvaliduntil<clock_timestamp())
FROM pg_authid WHERE rolname='article_expiry';
SQL
if PGPASSWORD=LAB-ONLY-OLD-PASSWORD psql -X -qAt -h 127.0.0.1 -p 55477 \
 -U article_expiry -d postgres -c 'SELECT 1' >"$lab_root/new.out" 2>"$lab_root/new.err"; then
 exit 1
fi
grep -q 'password authentication failed' "$lab_root/new.err"
printf '%s\n' 'fresh SCRAM login rejected after expiry'
printf "SELECT 'held after expiry='||current_user;\n" >&3
psql -X -qAt -v ON_ERROR_STOP=1 -h "$lab_root" -p 55477 \
 -U article_expiry -d postgres -c "SELECT 'local trust login='||current_user"
admin <<'SQL'
SET password_encryption='scram-sha-256';
ALTER ROLE article_expiry PASSWORD 'LAB-ONLY-NEW-PASSWORD';
SQL
if PGPASSWORD=LAB-ONLY-NEW-PASSWORD psql -X -qAt -h 127.0.0.1 -p 55477 \
 -U article_expiry -d postgres -c 'SELECT 1' >"$lab_root/rotated.out" 2>"$lab_root/rotated.err"; then
 exit 1
fi
grep -q 'password authentication failed' "$lab_root/rotated.err"
printf '%s\n' 'rotating password alone preserves expired deadline'
admin <<'SQL'
SELECT format('ALTER ROLE article_expiry VALID UNTIL %L',
 clock_timestamp()+interval '1 hour') \gexec
SQL
if PGPASSWORD=LAB-ONLY-OLD-PASSWORD psql -X -qAt -h 127.0.0.1 -p 55477 \
 -U article_expiry -d postgres -c 'SELECT 1' >"$lab_root/old.out" 2>"$lab_root/old.err"; then
 exit 1
fi
grep -q 'password authentication failed' "$lab_root/old.err"
printf '%s\n' 'old password rejected after rotation'
PGPASSWORD=LAB-ONLY-NEW-PASSWORD psql -X -qAt -v ON_ERROR_STOP=1 \
 -h 127.0.0.1 -p 55477 -U article_expiry -d postgres \
 -c "SELECT 'new password login='||current_user"
printf "SELECT 'held after rotation='||current_user;\n" >&3
printf '\\q\n' >&3
exec 3>&-
wait "$held_pid"
grep -qx 'held after expiry=article_expiry' "$lab_root/held.out"
grep -qx 'held after rotation=article_expiry' "$lab_root/held.out"
cat "$lab_root/held.out"

此前 PostgreSQL 18.6 记录中的输出确认截止时间已经过去；本轮没有重跑认证实验。脚本把期限设为数据库当前时间的一秒之后，然后等待数据库时钟越过它，所以这里实际经历了到期，而不是只拿一个编造日期做字符串比较。随后，通过 SCRAM 密码认证建立的新连接被拒绝，验证了真正决定认证结果的服务端规则。

到期之前打开的连接仍然可用。输入管道让同一个客户端和数据库会话跨过截止时间与密码替换过程，最后的输出确认它在两件事发生后都还能以该角色执行查询。如果需求是终止既有会话，就必须建立超出这个密码属性的明确策略；只观察新登录失败，并不能宣称此前的连接也已全部失去访问。

新的本地信任登录依然成功，这符合不同认证方式适用不同规则的文档契约。单独替换密码后，新的密码登录还是失败，因为原截止时间没有被重置。脚本再提供一个未来期限，替换后的密码才可以连接，而原密码被拒绝。这样分别验证了凭据值、有效日期和会话存续，不会把三件事合并成一个模糊的“轮换成功”。

实验最终明确了三项独立观察：期限影响新的密码认证；认证方式决定这条规则是否适用；已经建立的会话不会自动终止。示例没有实现生产凭据代理，也没有证明所有访问路径都能被统一撤销。实验完成后，专用集群与两条虚构密码一起被丢弃，不把这套仅为观察行为而设计的认证配置留在运行环境中。

在消费者需要重新连接之前完成更新

选择有效期时，应为获取替换值、分发、刷新消费进程，以及从有限中断中恢复预留时间。监控验证方剩余有效时间，也要观察每个消费者实际载入值的版本或年龄。管理清单显示已经产生新版本，并不证明运行中的应用已经使用新值，更不能代替一次真正的新连接测试。

平台的切换模型允许重叠时，应先用替换凭据完成新的认证，再退休旧版本。之后确认原凭据无法建立新访问，并单独决定是否排空或终止既有会话。发生泄漏时，紧急撤销可能优先于无中断切换；不能因为期限将来会到，就推迟当下应实施的撤销动作。流程目标是控制实际接受行为，而不是维持一个看起来整齐的轮换日历。

保持时钟同步，避免续期失败就悄悄延长有效期。记录被测主体、版本、验证方和期限，不记录秘密值。有效证据应包含预期边界前能接受、边界后在目标路径上被拒绝，以及对既有会话影响的清楚认识。管理界面显示了一个日期，只说明配置里存在这个字段，还没有证明系统执行了相应的访问限制。

来源

PostgreSQL 18 CREATE ROLE，密码专属有效期与非密码认证，已核验 2026-10-15。
PostgreSQL 18 ALTER ROLE，密码与有效期的独立修改，已核验 2026-10-15。
PostgreSQL 18 主机认证，认证规则匹配，以及信任认证和 SCRAM 的区别，已核验 2026-10-15。
OWASP 秘密管理，到期、轮换、撤销和生命周期控制，已核验 2026-10-15。

密钥 · XB 现场笔记

Kubernetes Secret 需要明确的访问边界

编码与保护处于不同层次

坏掉的样子

快速验证

延伸阅读

来源

ssh-agent 在会话期间替你记住已解密的密钥

套接字提供的是服务访问能力

同时限制身份与委托

坏掉的样子

快速验证

来源

凭据到期必须由验证方执行

坏掉的样子

快速验证

在消费者需要重新连接之前完成更新

延伸阅读

来源