后端认证鉴权密钥管理密码学【免费下载链接】openbaoOpenBao is a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys.项目地址https://gitcode.com/GitHub_Trending/op/openbao点击查看免费下载OpenBao 在 2024 年下半年迎来了一批由社区贡献者含 OpenBao Mentee 学员提交的 RFC 设计覆盖 SSH CA 轮换、PKI 策略校验、命名空间多租户、递归列表、ACL 过滤与分页、事务性存储以及加密原语升级等方向。本文以 2024 年 12 月官方 RFC 更新博文为主线逐一梳理这些 RFC 的设计动机、当前状态与底层实现依据并给出参与反馈的切入点帮助你快速判断哪些能力可以期待、哪些实现已经在仓库中落地。背景OpenBao 的 RFC 驱动治理OpenBao 作为一个从 HashiCorp Vault 分叉出来的开源机密管理项目其社区延续并强化了先 RFC、后实现的治理路径复杂功能先形成设计文档再由贡献者或临时工作组Working Group实现。2024 年下半年的这批 RFC 由多位社区成员提交其中包括 OpenBao Mentee 计划培养的学员。博文按进行中In-Progress、已完成Completed与规划中Upcoming三档分类本文沿用这一骨架展开。进行中的 RFCSSH CA 多签发者openbao#697设计动机Vault 与 OpenBao 在 SSH、PKI 两个引擎的 CA 轮换上长期存在问题。以往运维人员要么重新挂载一个全新引擎并手工复制配置与策略要么破坏性删除现有 CA 再重建期间会产生停机窗口。PKI 引擎在 Vault v1.11 已获得多签发者支持但 SSH 引擎一直没有同等能力。该 RFC 由 Mentee 学员 Gabriel 提出目标是为 SSH 引擎增加多签发者multi-issuer支持实现零停机 CA 轮换。源码佐证当前仓库的 SSH 引擎已经具备签发者相关的路径骨架。在 internal/builtin/logical/ssh/backend.go 中可以看到issuersLock写锁、issuerPrefix、issuer//public_key等路径注册以及config/issuers配置路径backend_test.go 中还包含TestSSHBackend_IssuerLifecycle测试覆盖未配置默认签发者时读取报错创建首个签发者自动成为默认等完整生命周期场景。从这些代码结构可以推断多签发者支持已经进入实现与测试阶段。如何参与如果你日常使用 SSH CA可对设计反馈意见实现者正在推进功能落地。PKI 策略的 CEL 表达式openbao#753设计动机PKI 引擎基于角色的证书校验方式不够灵活——每个证书字段、扩展以及对应的校验机制都要写死在引擎里用户必须等待新版本发布才能采纳新能力。例如角色上的allowed_domains目前不支持设置默认域名或拒绝只申请部分允许域名的请求。虽然功能上等价用户可以分多次申请各自域名的证书但 PKI 运维人员很难在单张证书中确认所有允许域名都已签发。Mentee 学员 Fatima 提出引入Google Common Expression LanguageCEL——GCP 与 Kubernetes 中广泛使用的校验/模板语言——用于基于请求参数强制签发策略并模板化最终证书。如何参与如果你有 CEL 使用经验或做过复杂的企业级 PKI 集成社区欢迎对该设计提出意见。命名空间支持openbao#787设计动机Vault Enterprise 的 Namespaces 提供了不运行多套集群即可实现多租户与权限委派的能力。OpenBao 社区多次提出类似需求因此成立了临时工作组Namespace WG负责设计与初始实现。该 RFC 由 Petergenelet发布目标是保持消费端 API 兼容同时为未来的可扩展性与租户隔离预留空间。源码佐证命名空间的核心数据结构已存在于 internal/helper/namespace/namespace.goNamespace结构体包含ID、UUID、Path、Tainted、ManuallySealed、Locked、CustomMetadata等字段根命名空间通过RootNamespaceID root与全零 UUID 标识Validate()会对路径做规范化Canonicalize并拒绝保留名reservedNamesauth、cubbyhole、identity等、空段、非法 UTF-8、空白字符与/*通配符HasParent/ParentPath提供了父子关系判断与父路径推导。从源码结构看命名空间的基础模型已经落地。如何参与初始实现由 Namespace WG 完成欢迎对设计反馈、参与功能测试或提交未来增强的设计与实现。递归列出密钥openbao#549设计动机这是 Vault 社区中最被广泛请求但长期没有解决方案的功能之一——递归列出密钥。在事务保证一致性与分页约束高开销调用的资源占用落地之前安全实现递归列表很困难。该 RFC 提议引入一个新操作HTTP 动词SCAN或通过GET加?scantrue查询参数并配套新增 ACL 能力scan使插件作者可以引入递归列表端点同时让运维人员能安全管控对这些端点的访问。源码佐证这一设计已经在 SDK 层落地。在 sdk/logical/request.go 中可以看到ScanOperation Operation scan的定义sdk/logical/storage.go 提供了ScanView与scanViewPaginated用于迭代扫描视图中的全部键并暴露分页 逐页回调cb(page, index, path)的细粒度控制同文件还有ClearViewWithPagination/ClearViewWithoutPagination两个工具函数。changelog 中的 1102.txt 也记录了ClearView、CollectKeys 与 ScanView 支持分页和事务的变更。如何参与初始实现合并后社区欢迎为更多端点接入这一新操作或提交相关 PR。ACL 改进过滤 LIST 结果与强制分页openbao#769 / openbao#791设计动机Vault 社区第四大被请求的功能是过滤 LIST 结果——只显示当前 token 策略下可访问的路径。该 RFC 提议在 ACL 策略中新增参数list_scan_response_keys_filter_path该参数是一个模板路径用于将 LIST 响应的每个条目来自.keys代入 ACL 系统检查在同一 token 策略下判断其可见性。由于该操作开销较大配套 RFC 又提出pagination_limit参数允许策略作者强制要求使用分页列表从而降低路径过滤的负载。源码佐证在 sdk/logical/auth.go 中可以看到ResponseKeysFilterPath string \json:list_scan_response_keys_filter_path 字段注释明确指出list 或 scan 请求需要对响应 keys 与 keysInfo 进行过滤——设计与实现已对齐。当前仓储代码中该字段已存在属于可验证的实现事实。如何参与社区特别欢迎对模板设计、以及多路径支持AND/OR组合行为的反馈。已完成事务性存储openbao#296内容这是 2024 年下半年已经合并并在 v2.1.0 发布的 RFC在 OpenBao 全栈从底层物理存储后端到插件层支持事务性存储。它使 OpenBao 的扩展性与容错能力超越了 HashiCorp Vault 的实现。源码佐证changelog 中 292.txt 记录了storage/raft: Add support for transactional storage semantics并说明新事务类型允许开发者开启只读与可写事务1102.txt 则进一步说明在 ClearView、CollectKeys、ScanView 中支持分页与事务改善密钥禁用时的内存消耗与请求一致性。Raft 存储层的相关实现细节还可结合 sdk/logical/storage.go 的接口设计阅读。如何参与后续的跟踪 issueopenbao#607邀请贡献者提交应使用事务的改进点同时也欢迎持续测试该能力。规划中加密原语与监听器能力升级XChaCha20-Poly1305 屏障加密支持openbao#235设计动机OpenBao 目前使用 AES256-GCM96 作为屏障加密算法。它足够安全且符合 FIPS 要求但 96 位 nonce 不具备碰撞抵抗性需要通过频繁密钥轮换来弥补。切换到XChaCha20-Poly1305后可以减少屏障密钥环规模无需自动密钥轮换并消除 nonce 碰撞顾虑。源码佐证SDK 的密钥管理工具已经为 XChaCha20 预留了类型与实现在 sdk/helper/keysutil/policy.go 中定义了KeyType_XChaCha20_Poly1305并同时支持chacha20poly1305.NewChaCha20-Poly1305与chacha20poly1305.NewXXChaCha20-Poly1305192 位 nonce两种构造器policy_test.go中也包含KeyType_XChaCha20_Poly1305的测试用例。目前该特性尚在 PoC 阶段。如何参与已有概念验证PoC方案社区在寻找志愿者继续打磨该特性。TLS 监听器的 ACME 支持openbao#17设计动机OpenBao 具备完整 PKI 能力但存在鸡生蛋问题——很难用存储在 OpenBao 中的 CA 为自己的 TLS 监听器签发证书。若配合 auto-unseal 与 ACME 支持这一场景将变得可行也能极大改善使用其他 CA 的运维体验。如何参与PoC 已提出但仍需大量打磨社区正在寻找接手开发的志愿者。如何参与反馈与贡献路径设计反馈对 SSH CA 多签发者、CEL 策略、命名空间、递归列表与 ACL 过滤等设计直接在对应 RFC 讨论区留言尤其是 CEL 多路径语义、list_scan_response_keys_filter_path模板行为等未定细节。功能测试事务性存储v2.1.0 起、ScanView/分页扫描sdk/logical/storage.go等已落地能力欢迎结合实际负载验证。接手实现XChaCha20-Poly1305sdk/helper/keysutil/policy.go 已有基础支持与 ACME 监听器仍缺主力贡献者。以上 RFC 的取舍体现了 OpenBao 社区的两个鲜明取向一是与 Vault 保持生态兼容但突破其局限如多签发者、事务性存储、递归列表二是优先落地底层基础设施事务、分页、扫描再在其上构建面向运维的新能力。对于关注多租户、CA 轮换与大规模密钥管理的用户上述 RFC 值得持续跟踪。赞分享后端认证鉴权密钥管理密码学【免费下载链接】openbaoOpenBao is a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys.项目地址https://gitcode.com/GitHub_Trending/op/openbao点击查看免费下载相关推荐LibrePhotos 2024 年 7 月开发进展日期相册 last_modified 增量查询与全端修复盘点LibrePhotos 2024 年 7 月开发进展日期相册 last_modified 增量查询与全端修复盘点 导读 本文依据 LibrePhotos 官方后端前端移动开发计算机视觉机器学习OpenBao 事务存储深度解析从快照一致性缺口到 Raft 与 PostgreSQL 的交互式事务实现OpenBao 事务存储深度解析从快照一致性缺口到 Raft 与 PostgreSQL 的交互式事务实现 OpenBaoOpenBao 是管理、存储和分发机后端认证鉴权密钥管理密码学2024年8月标签消费报表2024年8月标签消费报表 概览 统计周期2024 08 01至2024 08 31 总交易数127笔 总支出¥8,750.50 主要标签统计 | 标签后端金融科技上一篇3分钟搞定洛雪音乐音源新手也能轻松搭建全平台音乐库下一篇7个实用技巧Emoji Mart移动端性能优化指南显著降低CPU占用率创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考