authentik 统一身份认证（开篇）：为什么要统一登录，为什么选 authentik

随着公司发展，内部系统越堆越多：研发有 GitLab、Jenkins、Harbor，运维有 Prometheus、Grafana、JumpServer，全员还要连 VPN，除此之外各个部门之间还散落着许多自建的业务系统。员工每天都在“重置密码”和“想不起来密码”之间挣扎；管理员顾不过来这么多系统，新员工入职开号慢，老员工离职又总会漏关几个权限。这些问题平时只觉得是小麻烦，直到某天离职员工的未注销账号被利用，才会变成重大的安全事故。

这个系列记录了一家 500 人规模、用飞书做通讯录的公司，如何使用开源的 authentik 将上述系统整合到一个统一的账号体系下。作为系列开篇，本篇将重点聊聊：统一登录到底能带来什么价值？在众多同类产品中为什么最终拍板了 authentik？上线后，复杂的权限应该如何分层管理？以及在 Kubernetes 上部署到底需要跑哪些组件？

如果想直接看具体协议的配置实战，请移步架构与接入方式选型，以及本系列对 OIDC、代理认证、LDAP 和 RADIUS 四种协议的详细拆解。内容基于 authentik 2026.8 的官方文档。

TL;DR

统一登录的价值主要在离职和审计：一处禁用，所有系统同时拒绝登录；谁在什么时候登录了哪个系统，有一份完整记录。少记几个密码只是附带的好处。
选 authentik，是因为一个平台就覆盖了全部需求：OIDC、SAML、LDAP、RADIUS、代理认证都能提供，还能接飞书扫码。Keycloak 更成熟，但不对外提供 LDAP 和 RADIUS；Authelia 太轻；商业 IDaaS 按人头收费，数据也在外面。
开源版足够用：本系列用到的 OIDC、代理认证、LDAP、RADIUS、飞书接入、MFA、RBAC 都在开源版里；证书认证的 VPN（RADIUS EAP-TLS）、特权访问审批等属于企业版。
应用内的权限还是应用自己执行：authentik 在登录时把组和权益告诉应用。Grafana、Argo CD、Harbor、Jenkins 能按组自动映射角色；GitLab 只能映射管理员等全局身份（且要 Premium）；JumpServer 的资产授权要在它自己里面配。
权限分四层：应用绑定管“能不能进”，流程上的 policy 管“登录要过哪些关”，entitlements 和组管“进去后是什么角色”，RBAC 管“谁能改 authentik 本身”。应用没有任何绑定时，所有人都能进。
Kubernetes 上的核心 Pod 只有两种：authentik-server 和 authentik-worker，都是无状态的，各跑两个副本。另外有 LDAP、RADIUS outpost 各一组，以及飞书同步的 CronJob。2025.10 起不再需要 Redis。
PostgreSQL 是唯一的状态存储：生产环境用独立的数据库集群，不要用 Helm chart 自带的那个。

Open Table of contents

1. 统一账号登录对公司有什么用
- 1.1 野蛮生长下的痛点
- 1.2 统一登录的真正价值
2. 同类产品有哪些
3. authentik 能做什么
- 3.1 功能全景
- 3.2 开源版 vs 企业版
4. 权限是怎么控制的
5. 部署后会有哪些 Pod
6. 上线顺序建议
7. 生产取舍与踩坑经验
8. 参考资料

1. 统一账号登录对公司有什么用

1.1 野蛮生长下的痛点

500 个人，每人平均用 6 个内部系统，意味着全公司有近 3000 个分散在各处的账号。这种野蛮生长通常会带来以下痛点：

入职与转岗慢半拍：新人第一天常常在等 IT 逐个系统开号，而为了省事，往往直接给个高权限；转岗时，旧部门的权限基本没人记得回收，老员工往往能畅通无阻地进入全公司的系统。
离职漏关的高风险：管理员全凭记忆逐个系统停用账号，极大概率会漏掉一两个。离职漏关不会有系统报警，通常在被恶意利用后才会被发现。
密码疲劳与撞库：每个系统一套密码，员工为了方便只能全平台复用同一个密码。一旦某个边缘系统被攻破，核心系统也会面临撞库风险。
难以推行统一的安全策略：有些系统支持 MFA，有些不支持。最关键的业务系统，反而可能只有一层脆弱的密码保护。
审计记录碎片化：登录日志散落各处、格式不一，出事后很难拼凑出“谁在什么时候登录了哪里”的完整时间线。

1.2 统一登录的真正价值

把这些孤岛系统接到一个身份中心后，带来的改变是结构性的：

一处禁用，全网失效：这是统一登录最大的价值。员工离职时，飞书同步脚本自动禁用他在 authentik 里的账号，所有接入的系统会瞬间拒绝他的任何新登录尝试。
一套凭据，统一加固：员工只需用飞书扫码登录，再也不用为各种系统记忆密码；对于 JumpServer、生产环境 Argo CD 这类高危系统，可以在身份中心层面强制追加一次 MFA（二次验证）。
权限与组织架构联动：权限跟着“用户组”走。部门变了，所在的组自动变更，能够访问的系统也会自动增减，告别人工回收。
全局统一视角的审计：所有的登录、授权、失败尝试都汇聚在 authentik 的事件日志中，非常方便统一查询与告警。

不过，上线前也要和团队对齐预期，统一登录不是银弹：它拦不住已经建立的会话（禁用账号后，员工在 GitLab 已有的登录态还要靠缩短有效期或手动踢下线来解决）；它也不包揽应用内部的细粒度权限（authentik 只负责告诉 GitLab“这人是运维组的”，但哪个仓库能推代码，还是 GitLab 自己说了算）。此外，统一登录本身会成为全局单点，一旦它宕机，所有人都无法工作，因此高可用和应急通道是上线的硬前提（见第 5、6 节）。

2. 同类产品有哪些

2.1 先把需求列清楚

这家公司要接入的系统和它们支持的协议：

系统	支持的登录方式	需要身份中心提供
GitLab、Jenkins、Harbor、各业务系统	OIDC	OIDC
Prometheus、Alertmanager	没有登录功能	代理认证
JumpServer、部分老系统、Linux 主机	LDAP	LDAP 服务端
VPN、交换机、无线	RADIUS	RADIUS 服务端
员工登录身份中心本身	飞书扫码	接入飞书作为来源

再加上几条非功能需求：开源、能自己部署在 Kubernetes 上、500 人规模下运维简单、离职能通过 API 自动禁用。

2.2 候选产品怎么选

市面上的身份认证产品不少，但能同时满足上述所有协议的并不多。我们当时评估了以下几个选项：

authentik：一体化身份平台（Python + Go）。优势是全协议覆盖，OIDC、SAML、LDAP、RADIUS 都能对外提供，还内置了代理认证，并且能非常方便地把飞书作为上游身份源接入。缺点是社区规模不如 Keycloak，且版本迭代较快，需要投入一定的运维精力跟进升级。
Keycloak：最成熟的开源 IAM（Java，Red Hat 主导）。OIDC 和 SAML 的支持极其稳健，但不对外提供 LDAP 和 RADIUS 服务，代理认证也需要外挂 oauth2-proxy。如果选它，LDAP 和 RADIUS 还要另找方案，离职禁用就从“一处”变成了“三处”。
Authelia：轻量级反向代理认证（Go）。非常适合个人或小团队，但它没有管理后台，用户数据只能存在文件或依赖外部 LDAP，规模一大很难管理，且不支持对外提供 LDAP/RADIUS。
Zitadel / Casdoor：Zitadel 偏向面向 SaaS 产品的客户身份管理（B2B/B2C），不提供 LDAP/RADIUS；Casdoor 功能面很广，但各协议的实现深度和细节需要自己花时间验证。
FreeIPA / OpenLDAP：它们只是纯粹的目录服务，不是单点登录平台，要实现 OIDC 还需要在上面再叠一层。
商业 IDaaS（Okta、Entra ID 等）：功能完善，但按人头收年费，且员工身份数据必须托管在外部云端。

还有一个常被问到的选项：为什么不直接用飞书登录，省掉身份中心？ 飞书开放平台确实提供了网页应用登录，但大多数开源系统（如 GitLab、Grafana）并不认识飞书特有的 OAuth 接口，更不可能通过飞书去做 LDAP 和 RADIUS 认证。访问控制、审计日志也只能散落在各个系统里。飞书最适合的角色是“人员信息来源”，而不是直接充当“身份中心”。

2.3 为什么最终拍板 authentik

综合下来，authentik 是唯一一个能用单一部署解决所有问题的方案：

一个平台覆盖全部协议：OIDC、SAML、LDAP、RADIUS、代理认证，全部由同一套账号、同一套流程和绑定驱动。
登录流程高度可编排：登录过程由流程（flow）和步骤（stage）组成，可以在后台像搭积木一样拼装。比如“飞书扫码 → 检查是否离职 → 高危应用再验 TOTP”这种逻辑，用后台配置加几行 Python 表达式就能实现，完全不需要写插件。
部署足够简单：从 2025.10 版本起，它只依赖 PostgreSQL，Server 和 Worker 都是无状态的，加副本就能扩容；在 Kubernetes 上，LDAP、RADIUS 这些 Outpost 组件可以由 authentik 自动创建和升级。

当然，选择它也要接受它的代价：社区生态相对较小，遇到冷门问题能搜到的资料不多；官方只为最近的版本提供安全更新，必须将其排进日常运维计划中定期升级。

3. authentik 能做什么

3.1 功能全景

按用途分类，authentik 2026.8 提供的主要功能如下（未特别标注的均包含在开源版中）：

应用接入（Provider）：支持 OAuth2/OIDC、SAML、LDAP、RADIUS、代理认证（Proxy）。还支持远程访问（RAC：直接在浏览器里打开 RDP/SSH/VNC）、SCIM（将用户和组推送到下游应用），以及单点登出（Single Logout）。本系列重点使用 OIDC、代理认证、LDAP 和 RADIUS。
身份来源（Source）：支持将任意 OAuth/OpenID 服务、SAML、LDAP/AD 目录作为上游身份源接入，也支持 Kerberos 和接收 SCIM 推送。本系列使用 OAuth 来源接入飞书扫码。
登录步骤与 MFA（Stage）：登录过程可拆分为识别用户、密码校验、TOTP、WebAuthn/通行密钥（passkey）、Duo、短信、邮件验证码等步骤，还支持人机验证、授权同意页、重定向等控制逻辑。
访问控制：通过应用绑定（Binding）控制访问大门，通过策略（表达式、GeoIP、信誉防爆破等）控制登录条件，通过应用权益（Entitlements）向应用传递角色，以及通过 RBAC 控制管理后台的权限。本系列将全方位使用这些控制手段（见第 4 节）。
审计与通知：内置事件日志（默认保留 365 天），支持基于事件触发站内、邮件或 Webhook 通知。
运维与自动化：提供完整的 REST API 和 Terraform provider，支持用 YAML（Blueprints）即代码管理配置。支持多品牌（不同域名对应不同的登录页 UI），且 Outpost 组件能够在 Kubernetes/Docker 上实现自动部署与生命周期管理。

3.2 开源版 vs 企业版

authentik 企业版使用的是同一个容器镜像，导入 License 后即可解锁额外功能，License 在本地校验，完全支持离线/物理隔离环境。官方企业版功能中，与本系列场景相关的差异主要在以下几点：

无密码证书认证：企业版支持 RADIUS EAP-TLS（VPN/无线网络使用客户端证书认证，无需密码）以及管理后台的 mTLS 智能卡登录。开源版 RADIUS 仅支持 PAP（密码 + 动态码）。
自动化与合规：企业版提供定时离职（到点自动禁用用户并撤销会话）、特权访问申请（员工自助申请高危权限，审批后限时授予），以及增强的审计日志（记录配置变更的前后对比值）和 CSV 导出。开源版则需要通过飞书同步脚本来禁用账号，权限组走外部工单审批，审计依赖自行采集日志。
安全与风控：企业版提供 Account Lockdown（一键锁定被盗账号，立刻吊销 token 并切断会话），以及密码历史检查（防复用）。开源版在禁用账号后，需手动去清理残留会话。
下游同步：企业版支持将 authentik 的用户和组自动推送到 Google Workspace 和 Entra ID。

总体而言，500 人规模下，开源版完全足够跑通本系列的所有方案。真正值得企业去评估采购企业版的场景通常是：必须使用证书实现无密码 VPN、需要内置的特权访问审批流，或者出于合规要求需要商业支持和 SLA 保障。

4. 权限是怎么控制的

4.1 四层，各管一件事

很多人第一次看 authentik 的后台会困惑：有“绑定”、有“策略”、有“权益”、有“角色”、有“权限”，到底哪个管什么？把它们按回答的问题分开，就清楚了：

authentik 权限控制的四层：应用绑定、流程策略、应用内角色、RBAC 管理权限

前三层管员工能用什么，第四层管管理员能改什么。

4.2 第一层：能不能进这个应用

每个应用都可以绑定组、用户或策略（policy）。员工打开应用时，authentik 先检查这些绑定，不通过就直接拒绝，应用根本收不到请求。

没有任何绑定时，所有人都能访问。 这是最容易犯的错误，每接入一个应用都要检查。
有多条绑定时，由应用上的 Policy engine mode 决定怎么合并：Any（满足任意一条即可）或 All（必须全部满足）。
绑定也决定了员工在应用门户里能看到哪些应用：没有权限的应用，门户里不会显示。

推荐的组设计是两类组分开：

组的类型	举例	谁来维护	用途
部门组	`飞书/技术中心`、`飞书/技术中心/运维`	飞书同步脚本自动维护，不手工改	按部门授权：技术中心都能进 GitLab
权限组	`app-jumpserver`、`ops-admin`	走审批后由管理员维护，定期复核	跨部门、按需授权的高危权限

部门组跟着飞书走，转岗时自动变化；权限组不随部门自动变化，所以要定期复核。高危系统（JumpServer、生产发布）只绑定权限组，不绑定部门组。

4.3 第二层：登录时要过哪些关

应用绑定决定“谁能进”，流程上的策略决定“进之前要做什么”。流程由一个个步骤组成，每个步骤也可以绑定策略，决定这一步对谁生效。常用的策略类型：

表达式策略（Expression）：几行 Python，可以读用户、组、请求信息，最灵活。
GeoIP 策略：按登录来源的国家或 ASN 判断。
信誉策略（Reputation）：同一用户名或 IP 失败次数过多时拒绝，防暴力破解。

典型用法：所有人飞书扫码；ops-admin 组的人扫码后，再验一次 TOTP 或安全密钥。也可以只给某个高危应用换一条带 MFA 步骤的授权流程，详见 OIDC 篇的配置要点。

4.4 第三层：应用内角色映射实战

authentik 管到“进门”为止，进门之后能做什么全由应用自己决定：GitLab 里谁能推哪个仓库，Grafana 里谁能改哪个看板，authentik 都不直接参与。它能做的，是在登录成功时把“这个人是谁、属于哪些组、有哪些应用权益”抛给下游应用。

各协议向应用传递身份信息的方式如下：

OIDC：通过 ID token 和 userinfo 接口传递 groups、entitlements。
代理认证：通过 Nginx 向上游转发 X-authentik-groups 等 HTTP Header。
LDAP：反映在用户条目的 memberOf 和组条目的 member 属性中。
RADIUS：通过 Access-Accept 响应中的厂商自定义属性（Vendor-Specific Attributes）下发。

权益（entitlements） 是 2024.12 引入的特性，专门用来表达“某人在某个应用里的权限”。每个权益只属于一个应用，可以绑定给用户或组。它的好处是应用侧只认自己专属的几个权益名（比如 Grafana Admins），即便公司组织结构大调，应用的配置也无需修改。

那么应用拿到这些信息后怎么处理呢？这家公司几个主要系统的做法代表了三种典型的集成深度：

类型一：每次登录实时按组映射角色（推荐） 这是最省心的模式，权限完全由 authentik 决定，移出组后下次登录权限自动掉落。

Grafana：通过 entitlements 映射。在配置里写好 role_attribute_path，把特定的权益名映射为内部的 Admin、Editor、Viewer 角色，映射不上的统统给 Viewer。文件夹和看板的细粒度权限则留在 Grafana 内部配。
Argo CD：通过 groups 映射。在 argocd-rbac-cm 的 policy.csv 里直接把 authentik 的组名绑定到角色。支持按项目、应用、甚至具体操作（同步、删除等）细分，粒度极细。
Harbor：通过 groups 映射。OIDC 配置里把 OIDC Admin Group 填上管理员组，普通项目成员可以直接在 Harbor 的项目配置里按 authentik 的组名批量添加。
Jenkins：配合 OpenID Connect 认证插件和 Role-based Authorization Strategy 插件，直接把 authentik 的组名当作授权对象来分配文件夹和任务权限。

类型二：只能映射少数全局身份 应用只接受最高维度的权限映射，具体的业务权限仍需在应用内维护。

GitLab：Premium 及以上版本支持配置 groups_attribute。你可以用它结合 required_groups、admin_groups 等参数来决定某人能否登录、是不是全局管理员或外部用户。但注意，它不会自动把用户加进 GitLab 的具体群组或代码库中，代码层面的权限依然要在 GitLab 里分配。

类型三：只认人，权限全在应用里 authentik 只负责证明“这个人是谁”，其余所有授权规则都在应用内配置。

JumpServer：无论是接 LDAP 还是 OIDC，它在首次登录时自动建立用户，但最终的资产授权规则（谁能连哪台机器）完全在 JumpServer 内部按用户组配置。
Prometheus / Alertmanager：挂代理认证，不支持角色区分。只有“能进”和“不能进”两种状态。

以 Argo CD 为例，把 ops-admin 组设为管理员，研发负责人组 rd-leads 设为只读，其余人没有任何权限：

# argocd-rbac-cm
data:
  policy.default: ""
  policy.csv: |
    g, ops-admin, role:admin
    g, rd-leads, role:readonly
  scopes: "[groups]"

在应用内控制权限时，请牢记以下原则：

映射用“权限组或权益”，绝对不用“部门组”。飞书部门一改名，比如 飞书/技术中心/运维 变成了 飞书/基建中心/运维，所有硬编码了这个名字的应用配置会瞬间全部失效。应用侧只应该认 ops-admin 这种与组织架构解耦的稳定名字。
默认给最低权限。映射规则匹配不上时，默认降级到只读或无权限。比如 Grafana 的兜底写 Viewer，Argo CD 的 policy.default 留空。
应用里手工授予的权限必须定期复核。像 GitLab 的项目成员、JumpServer 的资产授权，这些脱离了 authentik 掌控的权限，在 authentik 的审计记录里是看不到的，必须纳入各系统自己的季度权限复核流程。
永远保留一个本地管理员。映射配错导致所有人被锁在门外，或者 authentik 宕机时，你需要靠它走后门进去修复。

4.5 第四层：谁能管理 authentik 本身

前三层管的是员工能用什么，第四层管的是管理员能在 authentik 后台做什么。从 2025.12 起，authentik 的管理权限完全基于角色（RBAC）：

角色就是一组权限的集合，角色可以分配给用户或组；分配给父组的角色，子组会自动继承。
权限分为两类：全局权限作用于某类对象的所有实例（例如“可以修改任意流程”）；对象权限只作用于某一个具体对象（例如“只能修改这个 LDAP provider”）。

合理的角色划分通常如下：

超级管理员：拥有全部权限（2 ～ 3 人，强制 MFA）。
服务台（Helpdesk）：只能查看用户、重置密码、发送恢复邮件。
应用管理员：仅拥有自己负责的几个应用和 Provider 的对象权限。
安全审计：仅拥有事件日志的只读权限。
同步账号：拥有创建、修改、禁用用户和组的权限（分配给飞书同步脚本）。

切记：RBAC 只管 authentik 里的对象，不管谁能访问下游应用。给某人赋予了“查看 GitLab 应用对象”的权限，并不会让他能登录 GitLab；能不能登录 GitLab 永远只看第一层的绑定。

5. 部署后会有哪些 Pod

5.1 组件和拓扑

官方推荐使用 Helm chart 将 authentik 部署到 Kubernetes。部署完成并接入 LDAP、RADIUS 后，Namespace 里的拓扑如下：

authentik 在 Kubernetes 上的部署拓扑：server、worker、LDAP 和 RADIUS outpost、飞书同步 CronJob，以及外部 PostgreSQL

核心只有 Server 和 Worker 两种 Pod，状态全部下沉在 PostgreSQL 里。

整个集群里主要跑着这几类 Pod：

authentik-server（Helm 创建）：处理所有 HTTP 请求，包括管理后台、API、登录流程、OIDC/SAML 认证。内置的 Outpost 也跑在这里，负责提供代理认证。建议 2 个副本以上。
authentik-worker（Helm 创建）：执行后台异步任务，比如发邮件、事件通知、定时清理。它还负责通过 Kubernetes 集成去创建和更新独立的 Outpost。建议 2 个副本。
ak-outpost-ldap（Worker 自动创建）：对外提供 LDAP 服务，把 LDAP 的 bind 和 search 请求翻译成对 authentik 的 API 调用。
ak-outpost-radius（Worker 自动创建）：对外提供 RADIUS 服务，监听 UDP 1812 端口。
feishu-sync-<时间戳>（自建 CronJob）：定时拉取飞书通讯录，通过 authentik API 执行建号、改组、禁用等操作。
authentik-postgresql-0（Helm 可选创建）：Chart 自带的数据库，仅供测试，生产环境务必关掉。

关于部署架构，有几点需要特别注意：

彻底告别 Redis：2025.10 版本之前，authentik 强依赖 Redis 做缓存、任务队列和会话存储；从 2025.10 起，这些数据全部迁到了 PostgreSQL，Redis 被彻底移除。相应的，数据库连接数会比以前多出大约 50%，连接池上限需要按这个规模重新预估。
数据库迁移自动执行：没有单独的迁移 Job。升级时，先启动的 Server 副本会自动执行数据库迁移。因此升级前务必先备份数据库，以便迁移失败时回滚。
Outpost 的命名与扩容：Outpost Pod 的名字来自你在后台配置的名称（默认模板是 ak-outpost-<名称>）。它们的副本数、Service 类型（比如集群外的 JumpServer 要访问 LDAP，就需要 LoadBalancer 或 NodePort）都在后台的 Outpost 配置里调，不在 Helm values 里。
静态文件存储：应用图标、流程背景图等上传文件存在 /data 目录下，Chart 默认不挂载持久化存储。你可以配置 PVC 或 S3，或者干脆只用外部 URL 来引用图片。

kubectl get pods -n authentik 的样子大致如下：

NAME                                READY   STATUS      RESTARTS   AGE
authentik-server-6c8f9d7b5d-2xkqp   1/1     Running     0          3d
authentik-server-6c8f9d7b5d-9mzt4   1/1     Running     0          3d
authentik-worker-58d7c6f9b8-hq7wn   1/1     Running     0          3d
authentik-worker-58d7c6f9b8-vb2lc   1/1     Running     0          3d
ak-outpost-ldap-7f6b8c9d4f-k8s2d    1/1     Running     0          3d
ak-outpost-ldap-7f6b8c9d4f-p4nzr    1/1     Running     0          3d
ak-outpost-radius-5b9d7c8f6-r7wqm   1/1     Running     0          3d
ak-outpost-radius-5b9d7c8f6-xt5vj   1/1     Running     0          3d
feishu-sync-29371230-7hk2p          0/1     Completed   0          4m

5.2 Helm values 核心配置项

一个最小化的生产级配置，核心原则就是：关掉自带的测试数据库、接入外部 PostgreSQL、并保证 Server 和 Worker 至少双副本。

authentik:
  secret_key: "<用 openssl rand 60 | base64 生成>"
  postgresql:
    host: "authentik-pg-rw.database.svc"
    name: "authentik"
    user: "authentik"
    password: "<强烈建议从 Secret 注入>"

postgresql:
  enabled: false # 必须关闭 Chart 自带的测试数据库

server:
  replicas: 2
  ingress:
    enabled: true
    ingressClassName: nginx
    hosts:
      - auth.company.com

worker:
  replicas: 2

注意：上述配置中的密钥和数据库密码千万不要明文写在 values 文件里，生产环境应当使用 Secret 或外部密钥管理系统（如 Vault / External Secrets）进行注入。完整的可配置项请以 ArtifactHub 上的 Chart 官方文档为准。

5.3 高可用怎么做

Server 和 Worker 跨节点打散：这两个核心组件是完全无状态的，挂掉任意一个副本都不会中断服务。配合 Kubernetes 的 PodDisruptionBudget 和反亲和性（Anti-Affinity），确保在节点维护时它们不会被同时驱逐。思路与 K8s 调度与弹性伸缩中讲的一致。
PostgreSQL 是唯一的单点：请务必使用独立的高可用集群（例如 CloudNativePG 或 Zalando Postgres Operator），实现主从自动切换，并建立定期备份与恢复演练机制。
Outpost 也要多副本：LDAP 和 RADIUS Outpost 都是独立的进程，它们的可用性取决于你配置的副本数，以及前面负载均衡器的健康检查机制。
异地双活（Active-Passive）：如果要求极高，官方支持 Active-Passive 部署。两套 authentik 连同一个数据库，前端的负载均衡平时只把流量给主集群，故障时自动切到备集群。

500 人规模下，两个 Server、两个 Worker 的资源占用微乎其微。真正需要你花心思的，是保障数据库的稳定，以及留好应急通道。

6. 上线顺序建议

建议按风险从低到高，分批次逐步接入：

先把 authentik 自身地基打稳：完成高可用部署、数据库备份、监控告警接入，强制超级管理员开启 MFA，并妥善保管应急账号。
跑通飞书链路：打通扫码登录和通讯录同步，先在 IT 测试组内验证入职、转岗、离职这三种最核心的生命周期场景。
接入 OIDC 系统：从内部自建的边缘业务系统，或者 Grafana、Harbor 这类即使出点错影响也不大的系统开始，再过渡到 GitLab、Jenkins。每次接入前，务必先处理好存量账号的关联规则（详见 OIDC 篇）。
给无登录的系统加代理认证：如 Prometheus、Alertmanager（详见代理认证篇）。
最后啃 LDAP 和 RADIUS 的硬骨头：JumpServer、VPN 涉及让员工额外设置一套独立密码，沟通成本和员工不适感最高，建议放在最后（详见 LDAP 篇和 RADIUS 篇）。

7. 生产取舍与踩坑经验

风险集中了，防护也要集中。以前攻破一个边缘系统只能进那一个系统，现在只要攻破了员工的身份，就能长驱直入所有系统。因此，飞书账号必须全员开启二次验证，authentik 的超级管理员权限要极度收敛并强制 MFA，对于生产发布等高危系统，要在登录流程中再卡一道 authentik 自己的 MFA。
核心系统必须保留本地应急账号。如果 authentik 故障，运维连不上 VPN 和 JumpServer，也就没法连进内网去修复 authentik，这就成了死循环。VPN、JumpServer、云控制台、Kubernetes 集群必须各保留一个不依赖 authentik 的本地管理员账号。把凭据封存在少数人能访问的保险箱（或密码管理器）里，每季度演练一次“破窗登录”。
用流程兜底“没有任何绑定 = 所有人可进”。这是最容易酿成事故的默认行为。必须把“检查应用绑定”写进新系统的上线 Checklist 里；有条件的话，写个脚本定期通过 API 扫一遍没有任何绑定的高危应用。
权限组要定期复核。部门组会跟着飞书的人事调动自动变化，但手工分配的权限组（如 ops-admin）不会。每季度应导出一次高危权限组的成员名单，交由各系统负责人签字确认。
升级要紧跟，但别当小白鼠。新大版本发布后，最好等一两个补丁版本（Patch Release）再上生产；升级前仔细阅读 Release Notes 里的不兼容变更（Breaking Changes），并先在测试环境用生产数据的快照演练一次。