天生双下巴如果你已经在一台内网服务器上把 authentik 跑起来，并且正在用 Proxmox VE（PVE）管理虚拟机和容器，那这一步几乎是绕不开的刚需：让 PVE 不再维护独立的账号密码，而是通过 authentik 完成身份认证。简单说，就是把 PVE 的登录框“外包”给 authentik，实现一套账号密码走遍内网所有服务。这篇文章我重点讲 authentik 与 PVE 的 OIDC 集成，覆盖从 authentik 侧创建 Provider、到 PVE 侧添加 Realm、再到用户权限落地的完整过程，同时把部署以来踩过的典型问题整理成排查清单。适合已经装好 authentik 基础实例、想给虚拟化平台做统一身份认证的同学参考。
我自己的环境是 authentik 长期版 + PVE 8.x 系列，authentik 用 Docker Compose 部署，PVE 是标准的 8006 端口 Web 界面。这一篇是基于这套实验环境反复验证过的流程，版本不同时界面字段会有细微差别，但原理一致。
1. 为什么要先想清楚“PVE 登录接 authentik”这件事
1.1 PVE 原生认证体系的痛点
PVE 默认的认证体系其实很传统：节点本地保存 /etc/pve/user.cfg，管理员手动给每个人开账号、设密码、分配权限。两三台机器的时候问题不大，可一旦宿主机数量多起来，痛点很快就浮现了。
首先是密码分散在各节点上。员工离职、实习生临时借调、外包同学需要临时查看虚拟机状态，你要么在每个节点上逐个删账号，要么留着僵尸账号天天担心安全。其次是密码策略基本等于没有，大家习惯性用同一个密码，PVE 默认又不会强制你上多因素认证。哪怕你给某个人只开了只读权限，只要密码泄露，攻击者拿到的就是一台宿主机层面可接触的合法入口。
我当时决定引入统一身份认证，核心目的不是“显得专业”，而是把“谁可以登录”“登录后能干什么”“什么时候不该能登录”这三件事收口到一个地方管。authentik 正好承担这个角色，它支持 OAuth2/OIDC、SAML、LDAP 等多种协议，后端可以对接企业微信、飞书、LDAP 目录甚至本地数据库，而且可以配置 TOTP、WebAuthn 等多因素认证，开源许可也比较友好。对家用环境是小菜一碟，对小型团队来说也完全撑得住。
1.2 两条集成路线：OIDC 还是 LDAP
PVE 内置支持多种认证 Realm，其中最常见的两条路是 LDAP 和 OIDC。很多人习惯先想到 LDAP，因为 authentik 也提供一个嵌入式 LDAP 服务，看起来“企业目录都是这么干的”。但在 PVE 这个场景下，我更推荐 OIDC，原因很实际。
LDAP 的好处是能直接同步用户列表，PVE 可以拉取 authentik 里的用户目录，用户自动出现，不用手工创建。坏处是 authentik 的嵌入式 LDAP 不在默认部署里，需要单独起一个 ldap outpost，并且要映射到 authentik 的 User 和 Group，配置链路更长；密码校验虽然走 LDAP bind，但遇到密码过期、账号锁定这类状态时，提示信息也比较简略。
OIDC 走的是标准 OAuth2 授权码模式，PVE 只看 authentik 签发的 ID Token，不直接接触密码。集成后用户在本机浏览器里被重定向到 authentik 的登录页，完成验证后拿一个认证票据跳回 PVE。这条路的突出优势是：用户密码不会经过 PVE 节点，PVE 侧连密码散列都不用存；后续如果给 authentik 开了 TOTP 和 WebAuthn，登录 PVE 时这些多因素策略会一并生效，不需要在 PVE 上重复配置。
我做的选型对比可以参考这个表：
| 维度 | OIDC | LDAP |
|---|---|---|
| 配置复杂度 | 低，PVE 原生支持 | 中高，需要先部署 LDAP Outpost |
| 用户列表同步 | 不自动同步 | 可自动同步 |
| 密码存储位置 | authentik 侧，PVE 不接触 | PVE 通过 bind 验证，不直接存密码 |
| 多因素支持 | authentik 统一控制，生效最直接 | 取决于 LDAP 后端能力 |
| 适合场景 | 中小规模、Web 管理为主 | 需要用户目录自动同步、终端服务较多 |
1.3 集成后的认证链路
如果真的打算上 OIDC，心里要先有一条完整的认证链路，后面配置时才不会云里雾里。
用户访问 https://pve.example.local:8006 后，PVE 的 Web 界面发现当前没有有效票据，就带着自己的 Client ID 和回调地址，把浏览器重定向到 authentik 的授权端点。authentik 展示登录页，用户输入账号密码，如果开了多因素就再验证一次，然后 authentik 拿着授权码和 PVE 换取 ID Token。PVE 验证 Token 合法后，把 Token 里的用户名映射成 PVE 内部用户，例如 alice@authentik，最后给浏览器种一个 PVE ticket，整个登录过程完成。
我实际体验下来，这比想象中要快，只要两端配置正确，从点击登录到进入 PVE 面板大概 2 到 3 秒。难点不在这 3 秒，而在配置前有没有想清楚账号和权限映射。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 集成前的准备工作和参数规划
2.1 检查版本、网络与证书条件
在动手前，先确认两边的版本和网络条件。PVE 8.x 自带 OIDC 认证 Realm，但不同小版本在界面字段和默认配置上有细微差别，总体上建议至少是 PVE 8.1 之后的版本，我实测基于 PVE 8.2。如果你还在用 7.x，想走 OIDC 会比较别扭，建议优先考虑升级。
网络层面的要求很基础但容易忽略：PVE 节点要能访问 authentik 的地址，反过来 authentik 不一定需要