尧图网页设计 
后端认证鉴权密钥管理密码学【免费下载链接】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 的 Kubernetes 认证后端允许 Pod 内的 Kubernetes Service Account 直接向 OpenBao 进行身份认证从而在不暴露根 Token、不手工签发长期凭证的前提下安全地获取短期访问 Token。本文以 internal/builtin/credential/kubernetes/README.md 为骨架结合该模块的源码实现完整讲解如何启用后端、配置 API 连接信息、创建绑定 Role、发起登录以及如何构建、注册和测试这一认证插件。插件定位与认证模型Kubernetes 认证后端是一个凭证credential类后端插件它做的事情只有一件让 Kubernetes Service Account 能认证进 OpenBao。在本仓库中该插件位于 internal/builtin/credential/kubernetes/ 目录由 cmd/kubernetes/main.go 作为插件进程入口通过plugin.ServeMultiplex与kubeauth.Factory暴露给 OpenBao 主进程。插件默认被内置在 OpenBao 中默认挂载路径为auth/kubernetes因此只需一条命令即可启用$ bao auth enable kubernetes Successfully enabled kubernetes at kubernetes!说明原文档面向 HashiCorp Vault 编写示例命令使用vaultCLI在本仓库OpenBao中命令行客户端为bao登录方式见 cli.go 中的bao login -methodkubernetes。下文在展示原文档命令的同时会给出bao等价用法。安全模型以 Kubernetes 为可信第三方当前认证模型的核心理念是Kubernetes 本身被当作一个可信的第三方。工作负载向 OpenBao 提交其 Service Account 的 JWTOpenBao 需要验证两件事这个 JWT 是 Kubernetes密码学签名过的、能表达 Token 持有者身份的有效凭证这个 Token 在 Kubernetes 侧仍然真实存在、未被删除或吊销。第一点通过 JWT 签名与 Issuer/Audience 校验完成第二点通过调用 Kubernetes 的TokenReviewAPI 完成见下文登录流程。原文档也指出Service Account Token 属于敏感凭证不应随意共享未来若 Kubernetes 提供更轻量的机制插件会随之升级适配。快速开始启用认证后端在已经安装并运行 OpenBao并完成初始化、解封的前提下启用该后端的完整路径为# 1. 启用认证后端默认挂载在 auth/kubernetes $ bao auth enable kubernetes Successfully enabled kubernetes at kubernetes! # 2. 配置后端告诉 OpenBao 如何访问 Kubernetes API $ bao write auth/kubernetes/config \ kubernetes_hosthttps://192.168.99.100:8443 \ kubernetes_ca_certca.crt \ token_reviewer_jwttoken.jwt # 3. 创建一个 Role绑定某个 Service Account 与 Token 策略 $ bao write auth/kubernetes/role/demo-role \ bound_service_account_namesweb \ bound_service_account_namespacesdefault \ token_ttl1h \ token_policiesweb-readonly # 4. Pod 内使用 Service Account Token 登录 $ bao login -methodkubernetes roledemo-role JWT (will be hidden): 粘贴 /var/run/secrets/kubernetes.io/serviceaccount/token 的内容 Success! You are now authenticated.登录成功后OpenBao 会返回一个受 Role 中token_ttl、token_max_ttl、token_policies等参数约束的新 Token。后端配置config详解后端配置对应 API 路径auth/kubernetes/config负责描述 OpenBao 如何连接并信任 Kubernetes API。其字段定义在 path_config.go 的pathConfig()中关键参数如下参数类型说明默认行为kubernetes_hoststringKubernetes API Server 地址可以是 host、host:port 或完整 URL 基础路径必填写入时若为空直接报错 no host providedkubernetes_ca_certstring用于访问 API 的 TLS 客户端所信任的 PEM 编码 CA 证书为空时自动读取 Pod 内的/var/run/secrets/kubernetes.io/serviceaccount/ca.crt除非禁用本地 CAtoken_reviewer_jwtstring用于访问 TokenReview API 的 Service Account JWTBearer Token未设置时登录提交的那个 JWT会被用来访问 API为空时自动读取 Pod 内/var/run/secrets/kubernetes.io/serviceaccount/tokenpem_keyslist可选用于校验 Service Account JWT 签名的 PEM 公钥或证书列表证书会提取公钥。并非所有 Kubernetes 安装都会暴露这些密钥为空时不校验 JWT 签名见登录流程issuerstring可选的 JWT Issuer已弃用未来版本移除源码中默认值为kubernetes/serviceaccount见 path_login.go 的defaultJWTIssuerdisable_iss_validationbool是否禁用 JWT Issuer 校验已弃用未来版本移除默认truedisable_local_ca_jwtbool运行在 Kubernetes Pod 内时是否禁用默认读取本地 CA 证书与本地 Service Account JWT默认false从源码看pathConfigWrite会把配置序列化为kubeConfig存入config存储条目并把pem_keys逐条解析为公钥对象certutil.ParsePublicKeyPEM读取配置时pathConfigRead返回的字段中token_reviewer_jwt以布尔标志token_reviewer_jwt_set呈现避免回显敏感 JWT 明文。两个本地文件路径常量在源码中明确为localCACertPath /var/run/secrets/kubernetes.io/serviceaccount/ca.crt localJWTPath /var/run/secrets/kubernetes.io/serviceaccount/token本地 CA / JWT 的缓存与轮换机制backend.go 中通过cachingFileReader缓存本地文件本地 Service Account JWT 每1 分钟jwtReloadPeriod重读一次以支持 Token 轮换对应 Kubernetes 1.21 起的官方建议本地 CA 证书每1 小时caReloadPeriod重读一次。同时后端启动initialize时会启动一个 TLS 配置更新器runTLSConfigUpdater每 30 秒defaultHorizon最小 5 秒从存储重新读取配置把 CA 证书池同步到 HTTP 客户端的tls.Config中保证 CA 更换后无需重启即可生效。相关实现证据见 backend.go。一条重要的写入约束源码中pathConfigWrite有一条显式校验当disable_local_ca_jwttrue时必须同时提供kubernetes_ca_cert否则返回错误kubernetes_ca_cert must be given when disable_local_ca_jwt is true。在配置时需要注意这一约束。Role角色配置详解Role 对应 API 路径auth/kubernetes/role/name作用是把 Kubernetes Service Account 的身份元数据与 OpenBao Token 策略、TTL 等绑定在一起。字段定义见 path_role.go 的pathsRole()参数类型说明bound_service_account_nameslist允许使用该 Role 的 Service Account 名称列表设为*表示全部允许。必填且不能为空且*不能与其他值混用bound_service_account_namespaceslist允许使用该 Role 的命名空间列表设为*表示全部。若未设置 namespace selector则此项必填*同样不能与其他值混用bound_service_account_namespace_selectorstring以 JSON 或 YAML 对象表示的 namespace 标签选择器与bound_service_account_namespaces同时设置时二者取OR。仅支持matchLabelsmatchExpressions会被拒绝audiencestring可选校验 JWT 中的 Audience 声明alias_name_sourcestring派生 Alias 名称的来源serviceaccount_uid默认最安全形如474b11b5-0f20-4f9d-8ca5-65715ab325e0或serviceaccount_name形如vault/vault-agent即 namespace/serviceaccounttoken_policies/token_ttl/token_max_ttl/token_period/token_num_uses/token_bound_cidrs-通过tokenutil.AddTokenFields注入的标准 Token 参数决定登录成功签发的 Token 属性此外为兼容旧版本还保留policies、ttl、max_ttl、period、num_uses、bound_cidrs等已弃用字段写入时会通过tokenutil.UpgradeValue自动升级到token_*新字段见 path_role.go。Role 写入时的校验逻辑从pathRoleCreateUpdate源码可以看出创建/更新 Role 时会做如下强制校验bound_service_account_names不能为空*不能与其他名称/命名空间值混用can not mix * with valuesbound_service_account_namespaces与bound_service_account_namespace_selector至少提供一个namespace selector 必须是合法的 label selector 且不含matchExpressions见 namespace_validator.gotoken_ttl不能大于token_max_ttltoken_period、token_max_ttl不能超过后端最大租约 TTL超出token_max_ttl时仅发出截断警告。一个典型的完整 Role 示例$ bao write auth/kubernetes/role/web \ bound_service_account_namesweb \ bound_service_account_namespacesdefault \ audiencevault \ alias_name_sourceserviceaccount_uid \ token_ttl1h \ token_max_ttl24h \ token_policiesweb-readonly列表接口auth/kubernetes/role支持after与limit参数进行分页列举见 path_role.go。登录流程JWT 校验 TokenReview登录 API 为auth/kubernetes/login需要role与jwt两个必填字段其完整处理逻辑在 path_login.go 的pathLogin()中整体分三步第一步Role 与 CIDR 检查先按名称加载 Role若 Role 配置了token_bound_cidrs则校验客户端来源 IP 是否在允许范围内不匹配直接返回权限拒绝。第二步解析并校验 JWTparseAndValidateJWT支持的签名算法固定为 RS256/RS384/RS512、ES256/ES384/ES512supportedJwtAlgs若配置了pem_keys用其构建capjwt.NewStaticKeySet做严格签名验证若未配置公钥则跳过签名验证使用DontVerifySignature仅做结构解析——这正是文档建议配置pem_keys的原因若启用 Issuer 校验disable_iss_validationfalse按配置的issuer默认kubernetes/serviceaccount校验iss声明若 Role 设置了audience校验 JWT 的aud声明从 claims 中解码 Service Account 元数据名称、UID、命名空间、secret 名支持传统 SA Token 与 Projected Service Token 两种结构serviceAccount与projectedServiceToken结构体校验 Service Account 名称与命名空间是否命中 Role 的绑定名称、namespace 列表或 namespace label selector。第三步调用 Kubernetes TokenReview API 二次确认签名校验通过并不代表 Token 仍然有效。pathLogin接着调用serviceAccount.lookup通过 token_review.go 中的tokenReviewAPI.Review向 Kubernetes 发送POST /apis/authentication.k8s.io/v1/tokenreviews Authorization: Bearer token_reviewer_jwt 或登录 JWT请求体为authentication.k8s.io/v1的TokenReview对象含spec.token与spec.audiences。Kubernetes 返回后插件会校验status.authenticated必须为 true否则判定 JWT 无效若请求了 audience要求 Kubernetes 返回的status.audiences与期望值有交集解析status.user.username格式必须为system:serviceaccount:namespace:name并与 JWT claims 中解析出的 name、UID、namespace 逐一比对防止伪造 claims 与真实 Token 不一致。源码中的错误提示也很有参考价值当 TokenReview 返回 401 时通常意味着 Service Account 已被删除或重建Token 已变化对应错误信息lookup failed: service account unauthorized; this could mean it has been deleted or recreated with a new token。登录成功后的 Token 与元数据认证通过后pathLogin会构造logical.AuthAlias 名称按alias_name_source取 Service Account UID 或namespace/name在 Token 元数据中写入service_account_uid、service_account_name、service_account_namespace、service_account_secret_name与role便于后续审计与策略引用DisplayName形如namespace-name最后通过role.PopulateTokenAuth(auth, req)按 Role 的 Token 参数填充签发的 TokenTTL、MaxTTL、Period、Policies 等。Token 续期由pathLoginRenew处理续期时校验 Role 仍然存在并按其token_ttl/token_max_ttl/token_period重置租约见 path_login.go。CLI 登录方式cli.go 提供了两种命令行登录方式非交互模式下必须显式提供jwt否则报错拒绝从 stdin 读取# 方式一从 stdin 隐式输入 JWT $ bao login -methodkubernetes roledev-role JWT (will be hidden): # 方式二直接提供 JWT $ bao login -methodkubernetes roledev-role jwttoken默认挂载名为kubernetes可通过mount参数指定其他挂载路径。插件构建、注册与开发原文档给出的插件开发流程在本仓库中同样适用且仓库 Makefile 已把相关步骤脚本化。编译开发版插件需要本机安装 Go。编译插件二进制dev模式仅构建当前平台速度更快$ make dev对应 Makefile 中的实际命令为CGO_ENABLED0 go build -o bin/vault-plugin-auth-kubernetes cmd/vault-plugin-auth-kubernetes/main.go注本仓库插件入口位于 cmd/kubernetes/main.go构建产物名沿用了vault-plugin-auth-kubernetes的历史命名。配置 plugin_directory 并注册到插件目录把构建出的二进制放到 OpenBao 配置指定的插件目录例如 HCL 配置plugin_directory path/to/plugin/directory启动服务后把插件注册进 OpenBao 的插件目录plugin catalog$ bao plugin register \ -sha256插件二进制对应的 SHA256 值 \ -commandvault-plugin-auth-kubernetes \ auth kubernetes Success! Data written to: sys/plugins/catalog/kubernetes每次修改插件源码后都应重新生成 sha256 校验和例如使用 openssl$ openssl dgst -sha256 $GOPATH/vault-plugin-auth-kubernetes SHA256(.../go/bin/vault-plugin-auth-kubernetes) 896c13c0f5305daed381952a128322e02bc28a57d0c862a78cbc2ea66e8c6fa1注册完成后即可启用该认证后端$ bao auth enable kubernetes Successfully enabled plugin at kubernetes!单元测试与集成测试仓库提供了完整的测试体系单元测试不依赖外部集群# 运行全部测试 $ make test # 用 TESTARGS 过滤特定用例例如只跑配置相关测试 $ make test TESTARGS--runTestConfig集成测试需要安装 kind 创建真实 Kubernetes 集群Makefile 中的流程为# 1. 创建用于测试的 Kubernetes 集群 make setup-kind # 2. 构建插件并注册到集群内运行的 OpenBao 实例 make setup-integration-test # 3. 在集群内对 OpenBao 执行集成测试 make integration-test集成测试会通过kind创建集群默认v1.26.2用 Helm 在test命名空间部署 dev 模式的 OpenBao并应用 integrationtest/vault/tokenReviewerServiceAccount.yaml、tokenReviewerBinding.yaml 与 namespaceControllerBinding.yaml 等 RBAC 资源为 TokenReview 与 namespace 标签校验准备权限。测试用例本身也值得阅读integrationtest/integration_test.go 覆盖了成功登录、使用token_reviewer_jwt登录、namespace label selector 命中/不命中等场景如TestSuccess、TestSuccessWithNamespaceLabels、TestFailWithMismatchNamespaceLabels后者断言返回 403。单元测试文件则包括 path_config_test.go、path_role_test.go、path_login_test.go 等。安全注意事项敏感信息保护token_reviewer_jwt属于高敏感凭证后端将其存入SealWrapStorage见 backend.go读取配置时不回显明文建议在 Pod 中以挂载文件方式提供。建议配置pem_keys若不提供公钥插件会跳过 JWT 签名验证仅依赖 TokenReview 的二次确认安全强度下降在 Kubernetes 暴露公钥的环境下应尽量配置。责任披露若发现 OpenBao 安全问题请负责任地通过邮件openbao-securitylists.openssf.org私下披露切勿在公开渠道发布漏洞细节。密钥轮换本地 Service Account Token 与 CA 的轮换由后端的缓存重读机制JWT 每分钟、CA 每小时与 TLS 配置更新器共同保障无需重启 OpenBao。小结从启用后端、配置config、创建role到loginKubernetes 认证后端形成了一个完整闭环JWT 签名/声明校验确认你是谁TokenReview 二次确认你的凭证还活着Role 绑定决定你能拿到什么样的 Token。结合 path_config.go、path_role.go、path_login.go 与 token_review.go 等源码开发者可以完全掌握该后端的信任模型与每一步校验逻辑并借助仓库自带的 Makefile 测试体系安全地进行二次开发。赞分享后端认证鉴权密钥管理密码学【免费下载链接】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 JWT 认证后端vault-plugin-auth-jwt完全指南启用、配置、Provider 定制与测试OpenBao JWT 认证后端vault plugin auth jwt完全指南启用、配置、Provider 定制与测试 导读 本文以 OpenBao后端认证鉴权密钥管理密码学gogcli gog auth status 深度指南诊断认证配置与密钥环后端的终端工具gogcli gog auth status 深度指南诊断认证配置与密钥环后端的终端工具 导读 gog auth status 是 gogcliGoogleKubernetes HandbookKubelet HTTPS 端点的认证与授权配置指南Kubernetes HandbookKubelet HTTPS 端点的认证与授权配置指南 Kubelet 在节点上以 HTTPS 端点对外暴露了 /stat教程云原生容器编排创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenBao Kubernetes 认证后端（Kubernetes Auth）配置与登录流程深度指南
后端认证鉴权密钥管理密码学【免费下载链接】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 的 Kubernetes 认证后端允许 Pod 内的 Kubernetes Service Account 直接向 OpenBao 进行身份认证从而在不暴露根 Token、不手工签发长期凭证的前提下安全地获取短期访问 Token。本文以 internal/builtin/credential/kubernetes/README.md 为骨架结合该模块的源码实现完整讲解如何启用后端、配置 API 连接信息、创建绑定 Role、发起登录以及如何构建、注册和测试这一认证插件。插件定位与认证模型Kubernetes 认证后端是一个凭证credential类后端插件它做的事情只有一件让 Kubernetes Service Account 能认证进 OpenBao。在本仓库中该插件位于 internal/builtin/credential/kubernetes/ 目录由 cmd/kubernetes/main.go 作为插件进程入口通过plugin.ServeMultiplex与kubeauth.Factory暴露给 OpenBao 主进程。插件默认被内置在 OpenBao 中默认挂载路径为auth/kubernetes因此只需一条命令即可启用$ bao auth enable kubernetes Successfully enabled kubernetes at kubernetes!说明原文档面向 HashiCorp Vault 编写示例命令使用vaultCLI在本仓库OpenBao中命令行客户端为bao登录方式见 cli.go 中的bao login -methodkubernetes。下文在展示原文档命令的同时会给出bao等价用法。安全模型以 Kubernetes 为可信第三方当前认证模型的核心理念是Kubernetes 本身被当作一个可信的第三方。工作负载向 OpenBao 提交其 Service Account 的 JWTOpenBao 需要验证两件事这个 JWT 是 Kubernetes密码学签名过的、能表达 Token 持有者身份的有效凭证这个 Token 在 Kubernetes 侧仍然真实存在、未被删除或吊销。第一点通过 JWT 签名与 Issuer/Audience 校验完成第二点通过调用 Kubernetes 的TokenReviewAPI 完成见下文登录流程。原文档也指出Service Account Token 属于敏感凭证不应随意共享未来若 Kubernetes 提供更轻量的机制插件会随之升级适配。快速开始启用认证后端在已经安装并运行 OpenBao并完成初始化、解封的前提下启用该后端的完整路径为# 1. 启用认证后端默认挂载在 auth/kubernetes $ bao auth enable kubernetes Successfully enabled kubernetes at kubernetes! # 2. 配置后端告诉 OpenBao 如何访问 Kubernetes API $ bao write auth/kubernetes/config \ kubernetes_hosthttps://192.168.99.100:8443 \ kubernetes_ca_certca.crt \ token_reviewer_jwttoken.jwt # 3. 创建一个 Role绑定某个 Service Account 与 Token 策略 $ bao write auth/kubernetes/role/demo-role \ bound_service_account_namesweb \ bound_service_account_namespacesdefault \ token_ttl1h \ token_policiesweb-readonly # 4. Pod 内使用 Service Account Token 登录 $ bao login -methodkubernetes roledemo-role JWT (will be hidden): 粘贴 /var/run/secrets/kubernetes.io/serviceaccount/token 的内容 Success! You are now authenticated.登录成功后OpenBao 会返回一个受 Role 中token_ttl、token_max_ttl、token_policies等参数约束的新 Token。后端配置config详解后端配置对应 API 路径auth/kubernetes/config负责描述 OpenBao 如何连接并信任 Kubernetes API。其字段定义在 path_config.go 的pathConfig()中关键参数如下参数类型说明默认行为kubernetes_hoststringKubernetes API Server 地址可以是 host、host:port 或完整 URL 基础路径必填写入时若为空直接报错 no host providedkubernetes_ca_certstring用于访问 API 的 TLS 客户端所信任的 PEM 编码 CA 证书为空时自动读取 Pod 内的/var/run/secrets/kubernetes.io/serviceaccount/ca.crt除非禁用本地 CAtoken_reviewer_jwtstring用于访问 TokenReview API 的 Service Account JWTBearer Token未设置时登录提交的那个 JWT会被用来访问 API为空时自动读取 Pod 内/var/run/secrets/kubernetes.io/serviceaccount/tokenpem_keyslist可选用于校验 Service Account JWT 签名的 PEM 公钥或证书列表证书会提取公钥。并非所有 Kubernetes 安装都会暴露这些密钥为空时不校验 JWT 签名见登录流程issuerstring可选的 JWT Issuer已弃用未来版本移除源码中默认值为kubernetes/serviceaccount见 path_login.go 的defaultJWTIssuerdisable_iss_validationbool是否禁用 JWT Issuer 校验已弃用未来版本移除默认truedisable_local_ca_jwtbool运行在 Kubernetes Pod 内时是否禁用默认读取本地 CA 证书与本地 Service Account JWT默认false从源码看pathConfigWrite会把配置序列化为kubeConfig存入config存储条目并把pem_keys逐条解析为公钥对象certutil.ParsePublicKeyPEM读取配置时pathConfigRead返回的字段中token_reviewer_jwt以布尔标志token_reviewer_jwt_set呈现避免回显敏感 JWT 明文。两个本地文件路径常量在源码中明确为localCACertPath /var/run/secrets/kubernetes.io/serviceaccount/ca.crt localJWTPath /var/run/secrets/kubernetes.io/serviceaccount/token本地 CA / JWT 的缓存与轮换机制backend.go 中通过cachingFileReader缓存本地文件本地 Service Account JWT 每1 分钟jwtReloadPeriod重读一次以支持 Token 轮换对应 Kubernetes 1.21 起的官方建议本地 CA 证书每1 小时caReloadPeriod重读一次。同时后端启动initialize时会启动一个 TLS 配置更新器runTLSConfigUpdater每 30 秒defaultHorizon最小 5 秒从存储重新读取配置把 CA 证书池同步到 HTTP 客户端的tls.Config中保证 CA 更换后无需重启即可生效。相关实现证据见 backend.go。一条重要的写入约束源码中pathConfigWrite有一条显式校验当disable_local_ca_jwttrue时必须同时提供kubernetes_ca_cert否则返回错误kubernetes_ca_cert must be given when disable_local_ca_jwt is true。在配置时需要注意这一约束。Role角色配置详解Role 对应 API 路径auth/kubernetes/role/name作用是把 Kubernetes Service Account 的身份元数据与 OpenBao Token 策略、TTL 等绑定在一起。字段定义见 path_role.go 的pathsRole()参数类型说明bound_service_account_nameslist允许使用该 Role 的 Service Account 名称列表设为*表示全部允许。必填且不能为空且*不能与其他值混用bound_service_account_namespaceslist允许使用该 Role 的命名空间列表设为*表示全部。若未设置 namespace selector则此项必填*同样不能与其他值混用bound_service_account_namespace_selectorstring以 JSON 或 YAML 对象表示的 namespace 标签选择器与bound_service_account_namespaces同时设置时二者取OR。仅支持matchLabelsmatchExpressions会被拒绝audiencestring可选校验 JWT 中的 Audience 声明alias_name_sourcestring派生 Alias 名称的来源serviceaccount_uid默认最安全形如474b11b5-0f20-4f9d-8ca5-65715ab325e0或serviceaccount_name形如vault/vault-agent即 namespace/serviceaccounttoken_policies/token_ttl/token_max_ttl/token_period/token_num_uses/token_bound_cidrs-通过tokenutil.AddTokenFields注入的标准 Token 参数决定登录成功签发的 Token 属性此外为兼容旧版本还保留policies、ttl、max_ttl、period、num_uses、bound_cidrs等已弃用字段写入时会通过tokenutil.UpgradeValue自动升级到token_*新字段见 path_role.go。Role 写入时的校验逻辑从pathRoleCreateUpdate源码可以看出创建/更新 Role 时会做如下强制校验bound_service_account_names不能为空*不能与其他名称/命名空间值混用can not mix * with valuesbound_service_account_namespaces与bound_service_account_namespace_selector至少提供一个namespace selector 必须是合法的 label selector 且不含matchExpressions见 namespace_validator.gotoken_ttl不能大于token_max_ttltoken_period、token_max_ttl不能超过后端最大租约 TTL超出token_max_ttl时仅发出截断警告。一个典型的完整 Role 示例$ bao write auth/kubernetes/role/web \ bound_service_account_namesweb \ bound_service_account_namespacesdefault \ audiencevault \ alias_name_sourceserviceaccount_uid \ token_ttl1h \ token_max_ttl24h \ token_policiesweb-readonly列表接口auth/kubernetes/role支持after与limit参数进行分页列举见 path_role.go。登录流程JWT 校验 TokenReview登录 API 为auth/kubernetes/login需要role与jwt两个必填字段其完整处理逻辑在 path_login.go 的pathLogin()中整体分三步第一步Role 与 CIDR 检查先按名称加载 Role若 Role 配置了token_bound_cidrs则校验客户端来源 IP 是否在允许范围内不匹配直接返回权限拒绝。第二步解析并校验 JWTparseAndValidateJWT支持的签名算法固定为 RS256/RS384/RS512、ES256/ES384/ES512supportedJwtAlgs若配置了pem_keys用其构建capjwt.NewStaticKeySet做严格签名验证若未配置公钥则跳过签名验证使用DontVerifySignature仅做结构解析——这正是文档建议配置pem_keys的原因若启用 Issuer 校验disable_iss_validationfalse按配置的issuer默认kubernetes/serviceaccount校验iss声明若 Role 设置了audience校验 JWT 的aud声明从 claims 中解码 Service Account 元数据名称、UID、命名空间、secret 名支持传统 SA Token 与 Projected Service Token 两种结构serviceAccount与projectedServiceToken结构体校验 Service Account 名称与命名空间是否命中 Role 的绑定名称、namespace 列表或 namespace label selector。第三步调用 Kubernetes TokenReview API 二次确认签名校验通过并不代表 Token 仍然有效。pathLogin接着调用serviceAccount.lookup通过 token_review.go 中的tokenReviewAPI.Review向 Kubernetes 发送POST /apis/authentication.k8s.io/v1/tokenreviews Authorization: Bearer token_reviewer_jwt 或登录 JWT请求体为authentication.k8s.io/v1的TokenReview对象含spec.token与spec.audiences。Kubernetes 返回后插件会校验status.authenticated必须为 true否则判定 JWT 无效若请求了 audience要求 Kubernetes 返回的status.audiences与期望值有交集解析status.user.username格式必须为system:serviceaccount:namespace:name并与 JWT claims 中解析出的 name、UID、namespace 逐一比对防止伪造 claims 与真实 Token 不一致。源码中的错误提示也很有参考价值当 TokenReview 返回 401 时通常意味着 Service Account 已被删除或重建Token 已变化对应错误信息lookup failed: service account unauthorized; this could mean it has been deleted or recreated with a new token。登录成功后的 Token 与元数据认证通过后pathLogin会构造logical.AuthAlias 名称按alias_name_source取 Service Account UID 或namespace/name在 Token 元数据中写入service_account_uid、service_account_name、service_account_namespace、service_account_secret_name与role便于后续审计与策略引用DisplayName形如namespace-name最后通过role.PopulateTokenAuth(auth, req)按 Role 的 Token 参数填充签发的 TokenTTL、MaxTTL、Period、Policies 等。Token 续期由pathLoginRenew处理续期时校验 Role 仍然存在并按其token_ttl/token_max_ttl/token_period重置租约见 path_login.go。CLI 登录方式cli.go 提供了两种命令行登录方式非交互模式下必须显式提供jwt否则报错拒绝从 stdin 读取# 方式一从 stdin 隐式输入 JWT $ bao login -methodkubernetes roledev-role JWT (will be hidden): # 方式二直接提供 JWT $ bao login -methodkubernetes roledev-role jwttoken默认挂载名为kubernetes可通过mount参数指定其他挂载路径。插件构建、注册与开发原文档给出的插件开发流程在本仓库中同样适用且仓库 Makefile 已把相关步骤脚本化。编译开发版插件需要本机安装 Go。编译插件二进制dev模式仅构建当前平台速度更快$ make dev对应 Makefile 中的实际命令为CGO_ENABLED0 go build -o bin/vault-plugin-auth-kubernetes cmd/vault-plugin-auth-kubernetes/main.go注本仓库插件入口位于 cmd/kubernetes/main.go构建产物名沿用了vault-plugin-auth-kubernetes的历史命名。配置 plugin_directory 并注册到插件目录把构建出的二进制放到 OpenBao 配置指定的插件目录例如 HCL 配置plugin_directory path/to/plugin/directory启动服务后把插件注册进 OpenBao 的插件目录plugin catalog$ bao plugin register \ -sha256插件二进制对应的 SHA256 值 \ -commandvault-plugin-auth-kubernetes \ auth kubernetes Success! Data written to: sys/plugins/catalog/kubernetes每次修改插件源码后都应重新生成 sha256 校验和例如使用 openssl$ openssl dgst -sha256 $GOPATH/vault-plugin-auth-kubernetes SHA256(.../go/bin/vault-plugin-auth-kubernetes) 896c13c0f5305daed381952a128322e02bc28a57d0c862a78cbc2ea66e8c6fa1注册完成后即可启用该认证后端$ bao auth enable kubernetes Successfully enabled plugin at kubernetes!单元测试与集成测试仓库提供了完整的测试体系单元测试不依赖外部集群# 运行全部测试 $ make test # 用 TESTARGS 过滤特定用例例如只跑配置相关测试 $ make test TESTARGS--runTestConfig集成测试需要安装 kind 创建真实 Kubernetes 集群Makefile 中的流程为# 1. 创建用于测试的 Kubernetes 集群 make setup-kind # 2. 构建插件并注册到集群内运行的 OpenBao 实例 make setup-integration-test # 3. 在集群内对 OpenBao 执行集成测试 make integration-test集成测试会通过kind创建集群默认v1.26.2用 Helm 在test命名空间部署 dev 模式的 OpenBao并应用 integrationtest/vault/tokenReviewerServiceAccount.yaml、tokenReviewerBinding.yaml 与 namespaceControllerBinding.yaml 等 RBAC 资源为 TokenReview 与 namespace 标签校验准备权限。测试用例本身也值得阅读integrationtest/integration_test.go 覆盖了成功登录、使用token_reviewer_jwt登录、namespace label selector 命中/不命中等场景如TestSuccess、TestSuccessWithNamespaceLabels、TestFailWithMismatchNamespaceLabels后者断言返回 403。单元测试文件则包括 path_config_test.go、path_role_test.go、path_login_test.go 等。安全注意事项敏感信息保护token_reviewer_jwt属于高敏感凭证后端将其存入SealWrapStorage见 backend.go读取配置时不回显明文建议在 Pod 中以挂载文件方式提供。建议配置pem_keys若不提供公钥插件会跳过 JWT 签名验证仅依赖 TokenReview 的二次确认安全强度下降在 Kubernetes 暴露公钥的环境下应尽量配置。责任披露若发现 OpenBao 安全问题请负责任地通过邮件openbao-securitylists.openssf.org私下披露切勿在公开渠道发布漏洞细节。密钥轮换本地 Service Account Token 与 CA 的轮换由后端的缓存重读机制JWT 每分钟、CA 每小时与 TLS 配置更新器共同保障无需重启 OpenBao。小结从启用后端、配置config、创建role到loginKubernetes 认证后端形成了一个完整闭环JWT 签名/声明校验确认你是谁TokenReview 二次确认你的凭证还活着Role 绑定决定你能拿到什么样的 Token。结合 path_config.go、path_role.go、path_login.go 与 token_review.go 等源码开发者可以完全掌握该后端的信任模型与每一步校验逻辑并借助仓库自带的 Makefile 测试体系安全地进行二次开发。赞分享后端认证鉴权密钥管理密码学【免费下载链接】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 JWT 认证后端vault-plugin-auth-jwt完全指南启用、配置、Provider 定制与测试OpenBao JWT 认证后端vault plugin auth jwt完全指南启用、配置、Provider 定制与测试 导读 本文以 OpenBao后端认证鉴权密钥管理密码学gogcli gog auth status 深度指南诊断认证配置与密钥环后端的终端工具gogcli gog auth status 深度指南诊断认证配置与密钥环后端的终端工具 导读 gog auth status 是 gogcliGoogleKubernetes HandbookKubelet HTTPS 端点的认证与授权配置指南Kubernetes HandbookKubelet HTTPS 端点的认证与授权配置指南 Kubelet 在节点上以 HTTPS 端点对外暴露了 /stat教程云原生容器编排创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考