Authelia 集成 Kiali基于 OpenID Connect 1.0 实现服务网格可观测性平台单点登录【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia本指南面向在 Kubernetes 集群中部署 Kiali 服务网格可观测性平台的运维与开发人员讲解如何将 Kiali 作为 OpenID Connect 1.0 Relying Party依赖方接入 Authelia 提供的 OpenID Connect 1.0 Provider实现统一身份认证与单点登录SSO。读完本文你将掌握 Authelia 侧客户端注册的完整 YAML 配置、Kiali 侧 OpenID 认证策略的配置方法Kiali CR 与 Kubernetes Secret以及当 Kiali 存在 OIDC 兼容性缺陷时如何借助 Authelia 的 claims policy「逃生舱」Configuration Escape Hatch恢复登录功能。测试版本本集成指南基于以下版本撰写并验证Autheliav4.39.24Kialiv2.12.0本集成的支持等级为 community 级别见文档 front matter 中的support.level: community意味着该客户端由社区维护与验证配置可能随版本演进而变化。前置假设Assumptions本示例基于以下假设展开请根据你的实际部署环境替换对应值应用根地址Application Root URLhttps://kiali.example.com/Authelia 根地址Authelia Root URLhttps://auth.example.com/该地址同时也是 OpenID Connect 1.0 IssuerClient IDkialiClient Secretinsecure_secret上述域名使用example.com作为文档站点变量sitevar的默认值实际部署时应替换为你自己的域名。开始之前Before You Begin在配置任何 OpenID Connect 1.0 注册客户端之前有几个必须注意的通用事项源自 oidc-common 短代码client_id必须全局唯一本文示例中的kiali仅为演示可读性而使用不应在生产环境中使用。建议使用 64 个随机字符生成方式可参考 常见问题解答 中「How do I generate a client identifier or client secret?」一节。client_id只能包含 RFC3986 非保留字符且长度不得超过 100 个字符。client_secret必须妥善保管本文中的insecure_secret仅用于演示。Authelia 允许以明文存储但该行为已弃用未来版本不保证继续支持强烈推荐在配置中存储哈希后的密钥见下文 Authelia 配置中$pbkdf2-sha512$...格式的说明。当密钥以哈希形式存储时如果哈希工作因子work factor过高可能导致客户端认证超时请参考 常见问题解答 中「Tuning the work factors」一节调整。本文给出的 Authelia 配置只包含客户端注册部分你必须同时配置 OpenID Connect 1.0 Provider 配置 指南中要求的其余必填项如 issuer、密钥等。客户端注册仅展示了全部可用选项中的一小部分建议完整阅读 OpenID Connect 1.0 Clients 配置 以了解每个选项的作用。已知缺陷Kiali 对 OpenID Connect 1.0 的支持不完整本文档对应的 Kiali 版本存在已知的显著缺陷claims hydration该客户端并未真正支持 OpenID Connect 1.0因为它没有遵循规范要求的流程去获取它需要的 claims——即没有使用 Access Token 向 UserInfo 端点请求 claims。这意味着仅按标准方式配置很可能无法完成登录需要额外的「逃生舱」配置来绕过此缺陷详见下文 配置逃生舱 一节。此外与多数此类客户端类似Kiali 可能不将身份提供方的sub与issclaims规范保证不变绑定到本地账户而是使用email等可变 claim这可能带来账户提权风险claim binding 问题。规范要求客户端只能通过sub与iss组合锚定账户详见 OpenID Connect 1.0 Section 5.7 Claim Stability and Uniqueness。Authelia 侧配置以下 YAML 是用于 Kiali 的 Authelia 客户端配置 示例identity_providers: oidc: ## The other portions of the mandatory OpenID Connect 1.0 configuration go here. ## See: https://www.authelia.com/c/oidc clients: - client_id: kiali client_name: Kiali client_secret: $pbkdf2-sha512$310000$c8p78n7pUMln0jzvd4aK4Q$JNRBzwAo0ek5qKn50cFzzvE9RXV88h1wJn5KGiHrD0YKtZaR/nCb2CJPOsKaPK0hjf.9yHxzQGZziziccp6Yng # The digest of insecure_secret. public: false authorization_policy: two_factor require_pkce: false pkce_challenge_method: redirect_uris: - https://kiali.example.com/kiali scopes: - openid - email response_types: - code grant_types: - authorization_code access_token_signed_response_alg: none userinfo_signed_response_alg: none token_endpoint_auth_method: client_secret_post关键配置项说明配置项值说明client_id/client_namekiali/Kiali客户端标识与显示名称client_secretPBKDF2-SHA512 哈希insecure_secret的哈希摘要。使用哈希存储可避免明文泄漏推荐做法明文存储已弃用publicfalse机密客户端confidential client需要在 Token 端点进行客户端认证authorization_policytwo_factor该客户端要求两步验证2FA可根据你的安全策略改为one_factor或bypassrequire_pkce/pkce_challenge_methodfalse/ 空本示例未启用 PKCEKiali 端支持有限生产环境建议结合客户端能力评估是否启用redirect_urishttps://kiali.example.com/kiali授权码回跳地址必须与 Kiali 实际部署地址一致否则授权请求会被拒绝scopesopenid、emailKiali 通过emailclaim 识别用户名见下文username_claim: emailresponse_typescode仅使用标准授权码流程Authorization Code Flowgrant_typesauthorization_code与response_types: code对应access_token_signed_response_alg/userinfo_signed_response_algnone访问令牌与 UserInfo 响应不做 JWT 签名以兼容 Kialitoken_endpoint_auth_methodclient_secret_post客户端通过 POST 表单在 Token 端点提交密钥认证关于response_types、grant_types、token_endpoint_auth_method的取值约束与各客户端类型默认行为可参考 OpenID Connect 1.0 集成介绍 中的「Parameters」与「Client Authentication Method」章节以及 客户端配置文档。Kiali 侧配置配置 Kiali 有两种方式通过 配置文件Kiali CR 或通过 环境变量。本文以 Kiali CR 为主进行说明。配置文件Kiali CR调整你的 Kiali CR YAML 文件将认证策略切换为 OpenIDspec: auth: strategy: openid openid: client_id: kiali disable_rbac: true issuer_uri: https://auth.example.com scopes: [openid, email] username_claim: email各字段说明strategy: openid启用 OpenID Connect 认证策略client_id: kiali与 Authelia 中注册的client_id保持一致disable_rbac: true禁用 Kiali 自身的 RBAC 角色解析用户通过认证即可访问可根据你的授权需求调整issuer_uriAuthelia 的 OpenID Connect 1.0 Issuer 地址即https://auth.example.com不含末尾斜杠。Kiali 会基于该地址自动发现/.well-known/openid-configuration等元数据端点scopes: [openid, email]与 Authelia 客户端注册中的 scopes 对应username_claim: email使用 UserInfo 中的emailclaim 作为 Kiali 的用户名标识。创建 OpenID Connect 客户端密钥 Secret由于 Kiali 的 OpenID 策略无法直接读取 Authelia 侧哈希后的密钥还需要在 Kubernetes 中创建包含明文 Client Secret 的 Secret 对象该 Secret 由 Kiali 用于向 Authelia Token 端点认证apiVersion: v1 kind: Secret metadata: name: kiali namespace: istio-system labels: app: kiali type: Opaque stringData: oidc-secret: insecure_secret注意此处的insecure_secret必须与 Authelia 配置中哈希对应的原始密钥一致namespace需改为 Kiali 实际部署的命名空间。环境变量除 Kiali CR 外Kiali 同样支持通过环境变量注入同等配置AUTH_STRATEGY、AUTH_OPENID_CLIENT_ID、AUTH_OPENID_ISSUER_URI、AUTH_OPENID_SCOPES、AUTH_OPENID_USERNAME_CLAIM等具体变量名请以 Kiali OpenID Connect 策略官方文档 为准。两种方式二选一配置内容保持一致即可。配置逃生舱Configuration Escape Hatch正如「开始之前」所述Kiali 存在 claims hydration 缺陷它不会使用 Access Token 调用 UserInfo 端点获取 claims也不支持claims 请求参数。Authelia 为此提供了逃生舱机制通过为客户端配置claims_policy将原本应通过 UserInfo 端点获取的 claims 直接注入 ID Token从而恢复 Kiali 的登录功能。逃生舱配置示例由 oidc-escape-hatch-claims-hydration 短代码 生成的内容identity_providers: oidc: claims_policies: kiali: id_token: [rat, groups, email, email_verified, alt_emails, preferred_username, name] clients: - client_id: kiali claims_policy: kiali该配置创建了一个名为kiali的 claims policy将email、preferred_username等 claims 显式放入 ID Token并应用到kiali客户端。它本质上是将 claims 参数功能引入之前claims parameter 引入前的行为恢复出来专门用于那些不支持 UserInfo 端点或 claims 参数的有缺陷客户端。需要说明的是依据 OpenID Connect 1.0 Claims 指南规范的实现方式应当是客户端使用 Access Token 向 UserInfo 端点获取 claimsRequesting Claims using Scope Values明确要求 claims 仅在 UserInfo 端点可用该逃生舱属于打破常规的应急手段break-glass measure仅在尽力而为best-effort基础上提供建议先推动 Kiali 官方修复其缺陷若项目停止维护或无力修复再使用该方案示例恢复了全部此前错误出现在 ID Token 中的 claims实际使用时应只保留你真正需要的 claims例如仅email按需裁剪该缺陷同时是客户端忽略 claim 稳定性要求只用sub与iss锚定账户的明显信号使用时应知悉其安全含义。完整接入流程回顾在 Authelia 的identity_providers.oidc.clients中注册kiali客户端含 redirect_uris、scopes、授权策略等在 Authelia 中追加claims_policies并为kiali客户端指定claims_policy绕过 Kiali 的 claims hydration 缺陷修改 Kiali CR将spec.auth.strategy设为openid并填写 issuer、client_id、scopes、username_claim在 Kubernetes 中创建包含oidc-secret的 Secret供 Kiali 在 Token 端点完成客户端认证访问https://kiali.example.com/kiali应被重定向至 Authelia 完成登录本示例配置为two_factor即需要第二因素验证随后回跳至 Kiali。参考与延伸阅读Kiali OpenID Connect 策略官方文档Authelia 的 OpenID Connect 1.0 集成介绍涵盖响应类型、Grant Types、客户端认证方式、端点实现等规范细节Authelia OpenID Connect 1.0 Clients 配置指南客户端注册的全部可选配置项Authelia OpenID Connect 1.0 Provider 配置指南Provider 层面的必填配置与 claims_policies、scopes 定义Authelia OpenID Connect 1.0 Claims 指南claims 参数、scope 定义与逃生舱机制的完整说明常见问题解答client_id / client_secret 生成、明文与哈希存储、工作因子调优等【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考