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）恢复登录功能。
测试版本
本集成指南基于以下版本撰写并验证：
- Authelia：v4.39.24
- Kiali：v2.12.0
本集成的支持等级为 community 级别（见文档 front matter 中的
support.level: community），意味着该客户端由社区维护与验证，配置可能随版本演进而变化。
前置假设（Assumptions）
本示例基于以下假设展开，请根据你的实际部署环境替换对应值：
- 应用根地址（Application Root URL）：
https://kiali.example.com/ - Authelia 根地址（Authelia Root URL）：
https://auth.example.com/（该地址同时也是 OpenID Connect 1.0 Issuer） - Client ID：
kiali - Client Secret：
insecure_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_name | kiali/Kiali | 客户端标识与显示名称 |
client_secret | PBKDF2-SHA512 哈希 | insecure_secret的哈希摘要。使用哈希存储可避免明文泄漏，推荐做法；明文存储已弃用 |
public | false | 机密客户端（confidential client），需要在 Token 端点进行客户端认证 |
authorization_policy | two_factor | 该客户端要求两步验证（2FA），可根据你的安全策略改为one_factor或bypass |
require_pkce/pkce_challenge_method | false/ 空 | 本示例未启用 PKCE（Kiali 端支持有限）；生产环境建议结合客户端能力评估是否启用 |
redirect_uris | https://kiali.example.com/kiali | 授权码回跳地址，必须与 Kiali 实际部署地址一致，否则授权请求会被拒绝 |
scopes | openid、email | Kiali 通过emailclaim 识别用户名（见下文username_claim: 'email'） |
response_types | code | 仅使用标准授权码流程（Authorization Code Flow） |
grant_types | authorization_code | 与response_types: code对应 |
access_token_signed_response_alg/userinfo_signed_response_alg | none | 访问令牌与 UserInfo 响应不做 JWT 签名，以兼容 Kiali |
token_endpoint_auth_method | client_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 文件，将认证策略切换为 OpenID：
spec: 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_uri：Authelia 的 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 端点获取 claims（
Requesting 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），仅供参考
