密钥

Kubernetes Secret 是用于保存工作负载所需机密值的 API 对象，提供专门的类型、消费路径和访问控制目标。但它不会让所有其他参与者都无法读取内容。设计边界时，需要同时考虑谁能取回对象、谁能创建消费者、谁能查看消费者输出，以及谁能管理运行它们的节点。仅区分配置对象与秘密对象，还不足以完成权限设计。 Secret 的边界既包括直接读取者，也包括能够创建消费者的主体。窄投射只限制这一次交付，不一定限制创建者。轮换还需要交付、重载和签发方验证。此图是概念示意，本轮没有执行集群实验。 编码与保护处于不同层次 在 JSON API 表示中，Secret 的 data 使用 base64；stringData 则便于在写入时提交字符串。Base64 无需密钥就能还原，并不是加密。这种表示也不能证明某个具体集群怎样保护底层存储。Kubernetes 文档说明，若未配置相应加密，秘密数据默认不在存储层加密。应核对实际 API 服务器和存储设置，不能看到编码文字就推断保密措施已经生效。 存储加密同样不会阻止获得授权的 API 读取者拿到数据。RBAC 中的 get、list 和 watch 权限都可能暴露 Secret 内容，广泛的列表权限并不只是允许查看对象名称。备份和诊断输出也需要保护。正常应用最终仍要获得可用值，因此，一旦有权消费数据的程序被控制，攻击者就已经进入这份数据的信任边界，不能靠编码再次隔离它。 ...

SSH 代理为公钥认证提供签名操作。对于普通软件密钥，加载加密私钥时会解锁相关材料，此后代理便可以使用它，不必每次连接都重新询问文件口令。正常代理协议向客户端返回公钥身份和签名，而不是导出私钥。硬件支持的身份有所不同：私钥可以一直保留在认证器里，并要求触摸或用户验证，不能把所有代理身份都描述成完整私钥必然存放在代理内存中。 套接字提供的是服务访问能力 OpenSSH 通常通过 SSH_AUTH_SOCK 查找代理，但客户端配置中的 IdentityAgent 可以选择另一个套接字，也可以关闭代理使用。知道路径并不等于有连接权限。套接字和父目录的权限都重要；root 以及与用户同身份运行的其他进程，则是需要考虑的威胁。环境变量本身不能代替操作系统隔离，隐藏路径也不是可靠的保护边界。 能够访问代理，并不保证每个签名请求都会成功。密钥约束、确认要求、硬件在场和协议限制都可能拒绝请求。即使签名成功，远端服务器也不必接受这把密钥或授予权限。因此，本地签名能力与服务端授权决定应分开观察。诊断“代理里有钥匙但登录失败”时，不能只停留在身份列表这一层。 同时限制身份与委托 ssh-add 加载身份，并在需要时询问文件口令。但 ssh 的 AddKeysToAgent 等配置路径也能加载身份，不能说只有 ssh-add 才可能解锁。代理避免反复读取加密私钥文件，却不保证交换空间、转储、备份或其他进程中绝不存在私钥材料。操作系统与密钥存储策略仍然需要独立审阅，代理不是整台机器的保密证明。 -t 为添加的身份设置存活期限。到期后身份会被移除，这个参数不只是提醒；代理也可以提供默认期限；两种期限都没有时，普通身份才可能一直留到显式删除或代理退出。移走、删除或者替换磁盘文件，并不会自动替换代理里已经加载的副本。轮换时应检查实际使用的指纹，而不是只确认文件名已经改变。 -c 通过 ssh-askpass 要求确认。决定是否批准的是辅助程序是否成功退出，而不是远端主机有没有终端。需要验证本地确认机制确实能工作，并拒绝意外请求。确认可以减少无人值守的使用，但仍需理解提示所代表的主机和操作，不能看到弹窗就习惯性通过，也不能把没有远端终端当作必然拒绝的证据。 OpenSSH 8.9 引入的目的地约束使用主机密钥进一步限制允许的认证路径。经过转发时，客户端与服务端都需要支持相关协议，已知主机信息也必须正确识别目标。恶意中转节点仍可绕开协作式 SSH 再次中继套接字，但签名仍受获准目的地限制。这不是防火墙；依赖约束前应核对兼容性、保持更新，并理解主机密钥变化对路径的影响。 坏掉的样子 代理转发允许远端在转发通道存在期间中继签名请求。那里的管理员或被入侵进程可能使用这份能力，而不需要提取私钥。没有必要时应避免转发，并查看客户端最终生效的配置；命令行没有 -A，不足以证明配置文件没有开启它。风险在于签名委托，不在于私钥文件一定已经复制到远端。 从代理删除身份，并不会撤销已经被复制的私钥、删除服务器 authorized_keys 中的条目，也不保证关闭已建立的 SSH 会话。反过来，服务端撤销授权可能阻止新登录，即使代理仍保存这把钥匙。恢复计划应分别处理受影响的副本、授权记录和活动会话，而不是把其中一个动作误当成全部撤销。 现代 OpenSSH 代理还限制远端加载提供方和部分 FIDO 签名用途，但识别远端客户端依赖协作式 SSH 转发；这些机制可减少把转发认证器用于 SSH 之外的特定风险。这些保护不是公开套接字或随意放宽选项的理由。不同版本和平台集成的默认值、套接字位置可能不同；排查时应阅读当前实现的文档，不能把某次输出的路径和权限数字当成永远成立的协议常量。 ...

只有负责决定是否允许访问的系统检查了适用截止时间，凭据才真的会到期。在资产清单里写一个日期，不会自动改变数据库或接口接受什么。较短有效期可以压缩被盗凭据继续建立新访问的时间窗口，但具体效果取决于认证机制，以及此前已经建立的会话、签发的其他凭据如何处理。秘密不是因为自身附带一行日期，就能独立让所有访问失效。 只有验证方执行期限，到期才会改变接受行为。PostgreSQL 历史实验分别展示新的密码认证、既有会话与 trust 认证。通用重叠模型只适用于支持的平台；轮换、续期与撤销需要各自的证据。 坏掉的样子 到期不会撤销已经发生的行为。复制出去的数据仍在外面，截止时间之前建立的会话也可能继续工作。攻击者还可能在原本有效的权限下建立另一条访问路径。因此，有效期只是限制后续使用的一种手段，还要结合权限范围、撤销机制、会话管理和对实际影响的调查。它并不能为一次泄漏造成的全部损失设定通用上限，也不能把过去的访问自动变成没有发生过。 PostgreSQL 的 VALID UNTIL 控制角色密码的有效时间，不控制角色是否存在，也不覆盖所有认证方式。使用非密码方式建立连接，就不会获得同样的截止检查。如果通过本地信任规则来测试密码到期，便可能误以为到期功能失效。判断结果之前，应先确认客户端实际命中了哪条认证路径，不能只看两次连接用了同一个用户名。 轮换与续期是两个不同变化。在 PostgreSQL 中，仅修改 PASSWORD 会保留 VALID UNTIL，仅修改 VALID UNTIL 也会保留原密码。更新流程如果只修改其中一项，可能导致应用依然无法重新连接，也可能让原值继续有效。一个连接池里的旧连接查询成功，不足以证明新凭据能够完成新的认证，因为它可能根本没有重新交出密码接受检查。 ...