lijianfei.com

在当今企业内部 IT 基础设施与极客私有云集群中，身份与访问管理（IAM / IdP）正面临着前所未有的割裂。现代微服务和云原生 SaaS 普遍推崇 OAuth 2.0 与 OpenID Connect（OIDC），企业级传统软件要求 SAML 2.0，老旧内部系统（如 NAS、内部 Wiki、网络设备、SonarQube）依然只能靠 LDAP 与 RADIUS 苟延残喘，而大量无内置鉴权逻辑的内部 Web 工具又极度依赖反向代理的 Forward Auth（前向认证）守门。

开源界长久以来的两座大山各有遗憾：Keycloak 功能全面却依托重量级 Java/Quarkus 运行时，空载内存动辄吞噬 1GB 到 2GB，启动缓慢且认证流水线设计极为僵化；Authelia 虽轻量专注，但主要定位于反代前向认证，缺乏完整的 SAML 2.0 IdP 能力、无法提供原生 LDAP/RADIUS 服务，且全靠磁盘静态 YAML 缺乏现代 Admin 控制台与动态策略编排能力。

开源项目 authentik（开源仓库：goauthentik/authentik，GitHub 25.5k+ Stars）以 “The authentication glue you need”（你所需的身份粘合剂）为定位，彻底打破了这一僵局。它将整个认证生命周期重构为可编程的 Flow-Stage（流程与阶段）状态机，在底层深度融合 Rust 高性能代理内核、Go 协议前哨 与 Python 领域编排引擎，并通过分布式 Outpost（前哨网格）与 Blueprints（身份即代码），构筑了一套现代、弹性且高吞吐的开源统一身份底座。

1. 痛点审视：传统开源 IdP 的工程断层与架构危机

要理解 authentik 的架构突破，必须先剖析传统自建身份体系在真实工程演进中所遭遇的典型断层：

flowchart LR
    subgraph HeterogeneousApp ["异构应用消费端"]
        A1["现代云原生 Web (OIDC / PKCE)"]
        A2["企业级企业应用 (SAML 2.0)"]
        A3["遗留工控与存储 (LDAP / RADIUS)"]
        A4["内部无鉴权面板 (Forward Auth)"]
    end

    subgraph TraditionalChaos ["传统方案拼凑与运维痛苦面"]
        T1["Keycloak<br/>(JVM 沉重开销 / 内存黑洞 / 流程僵化)"]
        T2["OpenLDAP + phpLDAPadmin<br/>(维护繁琐 / 无现代 MFA / 协议单一)"]
        T3["Authelia / OAuth2-Proxy<br/>(仅前向反代 / 缺乏完整 IdP / 无动态流)"]
    end

    A1 -.-> T1
    A2 -.-> T1
    A3 -.-> T2
    A4 -.-> T3

    classDef chaos fill:#ffebee,stroke:#c62828,stroke-width:1px,color:#b71c1c;
    classDef app fill:#e8f4f8,stroke:#0288d1,stroke-width:1px,color:#01579b;

    class T1,T2,T3 chaos;
    class A1,A2,A3,A4 app;

1.1 协议割裂导致的“多套用户孤岛”

在多数团队的基础设施中，往往存在 OpenLDAP 服务于网络与 Linux 机器，Keycloak 服务于前端 Single Page Application（SPA），Nginx 前挂载 Lua 或 Authelia 服务于内网面板。当员工入职或离职时，管理员必须在三到四个系统间手动同步账号，不仅极易出现权限残留的严重安全漏洞，更让多因素认证（MFA）与密码轮换政策形同虚设。

1.2 传统认证流程的硬编码死板

现实中的业务认证流程往往充满动态分支：

• 内部办公网 IP 允许用户名密码直接登入，外网访问必须强制触发 FIDO2 WebAuthn / Passkeys 硬件密钥校验；
• 属于 devops-core 组的用户登录生产堡垒机需触发强行双因子，普通组访问只读控制台只需基础鉴权；
• 首次登入必须强制签署保密协议（Consent）并补充工作邮箱。

在传统 IdP 中，这类定制通常需要侵入式重写 Java SPI 或编写晦涩的配置插件；而在许多轻量级认证网关中，此类需求更是根本无法实现。

1.3 集中式单体反代与跨网延迟矛盾

反向代理认证（Forward Auth）要求每一次 HTTP 请求都向认证服务发起子请求（Subrequest）。如果企业应用分布在多机房、多 VPC 或公有云边缘，所有网络请求全部回源至中心单体 IdP，不仅会造成数百毫秒的额外延迟，中心结点的网络抖动更会导致整站级雪崩。

2. 核心架构解构：Flow-Stage 可编程状态机引擎

authentik 区别于所有传统 IdP 的核心基石，在于其对 认证流程的纯函数抽象与状态机建模。在 authentik 的世界观中，认证、注册、密码找回、设备授权以及退出，都不是固定死板的控制器路由，而是由 Flow（流程）、Stage（阶段）与 Policy（策略）动态编译而成的执行管线。

flowchart TD
    subgraph FlowPlannerEngine ["FlowPlanner 动态规划管线 (authentik/flows/planner.py)"]
        Start(["用户发起认证请求 /if/flow/<slug>/"]) --> CheckAuth{"检测 Flow 前置要求<br/>(Require Unauth / Superuser 等)"}
        CheckAuth -- 不满足 --> Reject(["抛出 FlowNonApplicableException 终止"])
        CheckAuth -- 满足 --> PolicyEngineGlobal["执行 Flow 绑定的全局 Policies (IP/地理/时间)"]
        PolicyEngineGlobal -- 校验失败 --> DenyFlow(["阻断访问"])
        PolicyEngineGlobal -- 校验通过 --> InspectBindings["遍历 FlowStageBinding 列表 (按 Order 排序)"]
        
        InspectBindings --> EvaluateStagePolicy{"执行 Stage 绑定的 Policies<br/>(Group / MFA状态 / Python 表达式)"}
        EvaluateStagePolicy -- 命中且通过 --> AppendStage["压入 FlowPlan 执行栈<br/>(绑定对应 StageMarker)"]
        EvaluateStagePolicy -- 条件不满足 --> SkipStage["跳过当前 Stage"]
        
        AppendStage --> NextBinding{"还有未检查的 Binding ?"}
        SkipStage --> NextBinding
        NextBinding -- 是 --> InspectBindings
        NextBinding -- 否 --> CachedPlan["生成 FlowPlan 实例并写入 Redis 缓存"]
    end

    subgraph FlowExecutorEngine ["FlowExecutorView 交互式调度循环"]
        CachedPlan --> PopStage["提取当前首个待执行 Stage"]
        PopStage --> RenderChallenge["渲染 Challenge UI / 派发挑战<br/>(Password / WebAuthn / Prompt)"]
        RenderChallenge --> ClientResp["客户端提交表单 / WebAuthn 签名"]
        ClientResp --> ValidateChallenge{"Stage.challenge_valid() 校验"}
        ValidateChallenge -- 失败 --> RecordEvent["记录失败事件并刷新挑战"]
        ValidateChallenge -- 成功 --> StageOK["更新 Context (写入 pending_user / tokens)"]
        
        StageOK --> ReevalCheck{"当前 Stage 具备 ReevaluateMarker ?"}
        ReevalCheck -- 是 --> DynReplan["触发动态重排：基于当前用户重算后续 Stage"]
        ReevalCheck -- 否 --> HasMoreStages{"执行栈中是否还有剩余 Stage ?"}
        DynReplan --> HasMoreStages
        
        HasMoreStages -- 是 --> PopStage
        HasMoreStages -- 否 --> FinalLogin["执行 UserLoginStage<br/>(下发 Session / JWT 并重定向至目标)"]
    end

    classDef plan fill:#e8eaf6,stroke:#3f51b5,stroke-width:1px,color:#1a237e;
    classDef exec fill:#e0f2f1,stroke:#00897b,stroke-width:1px,color:#004d40;
    classDef check fill:#fff3e0,stroke:#fb8c00,stroke-width:1px,color:#e65100;

    class FlowPlannerEngine plan;
    class FlowExecutorEngine exec;
    class CheckAuth,PolicyEngineGlobal,EvaluateStagePolicy,ValidateChallenge,ReevalCheck,HasMoreStages check;

2.1 FlowPlan 与 StageMarker 的动态规划机制

在源码 authentik/flows/planner.py 中，FlowPlanner 负责在用户触达流程的第一时间，根据上下文动态计算出一份专属于该请求的扁平阶段栈 FlowPlan：

@dataclass(slots=True)
class FlowPlan:
    """FlowPlanner 的构建产物：承载待执行阶段序列与动态上下文"""
    flow_pk: str
    bindings: list[FlowStageBinding] = field(default_factory=list)
    context: dict[str, Any] = field(default_factory=dict)
    markers: list[StageMarker] = field(default_factory=list)

    def next(self, http_request: HttpRequest | None) -> FlowStageBinding | None:
        if not self.has_stages:
            return None
        binding = self.bindings[0]
        marker = self.markers[0]
        marked_stage = marker.process(self, binding, http_request)
        if not marked_stage:
            # Marker 判定跳过当前阶段，自动迭代下一阶段
            self.bindings.remove(binding)
            self.markers.remove(marker)
            return self.next(http_request)
        return marked_stage

核心设计精妙之处在于 “阶段标记器（StageMarker）” 与 “重评估机制（ReevaluateMarker）”：

1. 初始盲态规划：当匿名访问者进入默认认证流时，系统尚不知晓其真实身份，此时只激活“标识阶段”（Identification Stage，输入用户名/邮箱或触发 Passkeys 发现）；
2. 动态重评估触发：一旦标识阶段验证通过，pending_user 对象被注入 context。后续绑定的 ReevaluateMarker 会立即被激活，强制策略引擎基于该具体用户的属性（如是否开启 MFA、所属用户组、历史登录风险指纹）实时重排后续阶段；
3. 零冗余跳过：若用户已成功配置硬件安全密钥，则直接分流至 WebAuthn 阶段；若未启用，且策略允许回退，则引导至 TOTP 阶段或跳过，完全消除了静态写死的分支硬编码。

2.2 常见原子化阶段类型剖析

2.3 基于沙箱 Python 表达式的高级访问策略（ABAC）

除了开箱即用的用户组过滤、IP 地理围栏（GeoIP）外，authentik 提供了极其强大的 Expression Policy（表达式策略）。管理员可以在沙箱环境中执行轻量 Python 脚本，直接读取请求对象、地理信息与用户元数据，实现真正的属性级访问控制（ABAC）：

# 示例：仅允许研发核心组成员在办公网络免 MFA，外网访问则强行打标
remote_ip = request.http.client_ip
is_office_ip = remote_ip.startswith("192.168.10.") or remote_ip.startswith("10.0.")
user_groups = [group.name for group in user.ak_groups.all()]

if "infrastructure-admin" in user_groups:
    if not is_office_ip:
        # 外网管理员：强制标记上下文，要求必须经过 FIDO2 WebAuthn 校验
        context["flow_plan"].context["require_hardware_token"] = True
        return True
    return True

# 普通员工外网访问拦截
if not is_office_ip and "contractors" in user_groups:
    ak_message("外部兼职人员禁止在外网访问此系统！")
    return False

return True

3. 多语言异构工程：Rust 高性能代理核演化史

在早期版本中，authentik 主要是由纯 Python (Django + Gunicorn) 构筑。但随着其在全球企业级生产环境和高吞吐边缘代理中的普及，纯解释型运行时的痛点逐渐显现：

• 静态资源与反向代理网络 I/O 开销大：Gunicorn 工作线程处理长连接 WebSockets、大文件流式转发与 TLS 握手时，内存和 CPU 消耗极不经济；
• 高并发 Forward Auth 吞吐瓶颈：面对海量微服务的高频鉴权子请求，纯 Python 接口的延迟和 GC 停顿影响了网关的 P99 响应时间。

authentik 在现代版本中重构了底层架构，演进为 “Rust 入口内核 + Go 前哨 + Python 业务中枢” 的精妙三层架构：

graph TB
    subgraph ClientLayer ["外部流量与客户端接入"]
        HTTPSReq["HTTPS / WebSocket 请求<br/>(:9000 / :9443)"]
    end

    subgraph RustCoreRuntime ["Rust 统一进程底座 (ak-axum + Hyper + Tokio)"]
        AxumEntry["Rust Axum 统一监听网关<br/>(src/server/core.rs)"]
        RustlsTermination["Rustls / AWS-LC-RS<br/>(FIPS 兼容高性能 TLS 终止)"]
        BufferEngine["启动等待缓冲池<br/>(Startup 503 Retry / 预加载静态 HTML)"]
        StaticServe["塔式流式静态文件服务<br/>(Tower-HTTP 零拷贝资源加速)"]
        MetricsEngine["Prometheus 核心指标采集<br/>(:9300 /metrics)"]
        
        ProxyOutpostRust["Rust 原生 Proxy Outpost<br/>(src/outpost/proxy/)<br/>- Moka 高速内存缓存<br/>- Forward Auth 极速验证<br/>- 反向代理零拷贝转发"]
        UnixSockProxy["本地 Unix Domain Socket<br/>/ IPC 桥接通道"]
    end

    subgraph PythonEngine ["Python 业务与调度中枢 (Django / Celery / Gunicorn)"]
        DjangoCore["Django REST Framework<br/>(ORM 复杂查询 / Blueprints 声明 / FlowPlanner)"]
        CeleryWorker["Celery 任务调度器<br/>(证书自动轮换 / 外部 SCIM 同步 / 审计归档)"]
    end

    subgraph GoOutposts ["Go 专用二进制协议前哨 (cmd/*)"]
        LDAPOutpost["Go LDAP Server<br/>(ASN.1 BER 流解析 / 虚拟目录投影)"]
        RADIUSOutpost["Go RADIUS Server<br/>(UDP 协议栈 / 802.1X VPN 鉴权)"]
        RACOutpost["Go RAC Bastion<br/>(Guacamole WebSockets / RDP / SSH 网关)"]
    end

    HTTPSReq --> AxumEntry
    AxumEntry --> RustlsTermination
    AxumEntry --> BufferEngine
    AxumEntry --> StaticServe
    AxumEntry --> MetricsEngine
    AxumEntry --> ProxyOutpostRust
    
    AxumEntry --> UnixSockProxy --> DjangoCore
    ProxyOutpostRust -.->|"REST / WS 通信"| DjangoCore
    LDAPOutpost -.->|"API Token 校验"| DjangoCore
    RADIUSOutpost -.->|"API Token 校验"| DjangoCore
    RACOutpost -.->|"Session 握手"| DjangoCore

    classDef rust fill:#fbe9e7,stroke:#d84315,stroke-width:1px,color:#bf360c;
    classDef python fill:#e3f2fd,stroke:#1565c0,stroke-width:1px,color:#0d47a1;
    classDef go fill:#e0f7fa,stroke:#00838f,stroke-width:1px,color:#006064;

    class AxumEntry,RustlsTermination,BufferEngine,StaticServe,MetricsEngine,ProxyOutpostRust,UnixSockProxy rust;
    class DjangoCore,CeleryWorker python;
    class LDAPOutpost,RADIUSOutpost,RACOutpost go;

3.1 Rust 驱动的 Axum 统一接入层

查看 authentik 的 Cargo 构建清单 Cargo.toml 与入口 src/server/core.rs 可以发现，整个服务的外层已完全由 Rust 掌管：

• TLS 硬件级加速：使用基于 BoringSSL 分支的 aws-lc-rs 与 rustls 实现 FIPS 140-3 级加密终止，杜绝内存越界隐患；
• 冷启动平滑缓冲：后端 Python Gunicorn 在冷启动加载庞大 ORM 模型时，Rust 网关会自动劫持外部流量，返回优雅配置的 STARTUP_RESPONSE_HTML 或携带 Retry-After: 5 的 JSON 响应，绝不向浏览器暴露裸露的 502 Bad Gateway；
• PyO3 深度内联：在单体合一容器中，通过 PyO3 运行时桥接，实现 Rust 事件总线与 Python 解释器无缝通信。

3.2 纯 Rust 实现的 Proxy Outpost

在 src/outpost/proxy 中，authentik 团队彻底抛弃了早期的代理实现，使用 Rust 重构了反向代理前哨：

• Moka 并发缓存：用户 Session 令牌与授权声明被缓存在高并发并发哈希表（moka）中，读操作完全免去昂贵的数据库与 Redis 往返，Forward Auth 验证平均耗时压低至 0.3 毫秒以内；
• 流式透明反代：基于 hyper 与 tower-http 实现双向流式零拷贝转发，原生承载 HTTP/2 与长连接 WebSocket。

4. 分布式 Outpost 网格：Zero Trust 边缘与异构协议救赎

在企业网络中，并非所有应用都能改造成规范的 OIDC/SAML 客户端。authentik 的核心杀手锏，在于其独特的 Outpost（前哨）体系。

flowchart TD
    subgraph HQ ["企业中心集群 / 数据中心"]
        AuthServer["authentik Core<br/>(PostgreSQL + Redis + Server)"]
    end

    subgraph BranchOffice ["边缘分支机构 / 独立 VPC / DMZ"]
        DockerOutpost["Docker 托管 Proxy Outpost<br/>(反代边缘 Grafana / Prometheus)"]
        LDAPAgent["Go 独立 LDAP Outpost<br/>(本地提供 ldaps://:636)"]
        RACAgent["Go RAC 堡垒前哨<br/>(隔离区内网 SSH / RDP 跳板)"]
        
        LegacyNAS["群晖 Synology / TrueNAS"]
        LegacySwitch["Cisco / H3C 核心交换机"]
        InternalNode["内网开发机 (Ubuntu SSH)"]

        DockerOutpost -->|"透明反向代理"| Grafana["内网监控看板"]
        LegacyNAS -->|"LDAP 查询 (389/636)"| LDAPAgent
        LegacySwitch -->|"802.1X RADIUS (1812)"| LDAPAgent
        RACAgent -->|"本地 RDP/SSH 直连"| InternalNode
    end

    DockerOutpost <== "WebSocket 长连接 / API Token 握手" ==> AuthServer
    LDAPAgent <== "出站加密 API 同步 (无需暴露内网端口)" ==> AuthServer
    RACAgent <== "出站安全通道" ==> AuthServer

    classDef central fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1px,color:#4a148c;
    classDef edge fill:#e8f5e9,stroke:#2e7d32,stroke-width:1px,color:#1b5e20;

    class AuthServer central;
    class DockerOutpost,LDAPAgent,RACAgent edge;

4.1 三种部署编排形态

1. 嵌入式前哨（Embedded Outpost）：直接在 authentik 核心主进程中运行，零额外容器开销，适合单机部署与极客 HomeLab；
2. 控制器自动托管（Managed Outpost）：管理员仅需在 Web 界面配置 Docker Socket 或 Kubernetes Ingress 类，authentik 内部控制器会自动通过 API 在目标主机或集群中创建、更新、水平扩容 Outpost 容器并管理证书；
3. 独立分布式前哨（Standalone Outpost）：运行在异地边缘机房或隔离 VPC 内。Outpost 仅需单向出站访问 中心 authentik 的 HTTPS API，即可自动拉取应用规则并在本地提供低延迟鉴权，天然契合跨云与多分支机构的混合云架构。

4.2 两种反代鉴权拓扑对比

A. Forward Auth 模式（前向反代守门）

现有入口网关（如 Traefik、Nginx、Caddy）负责公网 TLS 终结与路由，仅将每个请求的头部通过子请求（Subrequest）发送给 authentik Outpost。

浏览器 --> Nginx/Traefik --> (1. 子请求鉴权) --> authentik Outpost
                                 | (2. 鉴权通过，注入 X-authentik-username)
                                 v
                            实际后端容器服务 (如 Portainer, Jellyfin)

• 优势：对现有反代架构无侵入，原有证书申请与路由规则完全保持不变；
• 标头穿透：Outpost 校验 Cookie 成功后，自动向上游服务注入 X-authentik-username、X-authentik-email、X-authentik-groups，无鉴权能力的应用亦可直接识别当前登录者。

B. Single Application 模式（独立透明代理）

authentik Proxy Outpost 本身充当第一线反向代理，直接绑定公网域名并直接向内网后端发起 Proxy Pass。

• 优势：开箱即用，无需配置外部复杂的反代服务器，Outpost 自动处理所有重定向、Cookie 校验与错误拦截；
• 高级特性：原生集成 Backchannel 注销，用户在 authentik 中心注销时，Outpost 能够主动清除本地连接上下文。

4.3 赋能老旧资产：LDAP 与 RADIUS Outpost 的降维打击

在传统 IT 场景中，让一台十几年前制造的硬件存储设备（如旧款 NetApp、老旧 QNAP NAS）支持现代 WebAuthn 指纹登录无异于天方夜谭。

authentik 通过 Go 编写的 LDAP Outpost 巧妙化解了这一难题：

1. LDAP Outpost 在内网监听 389 与 636 端口，对外伪装成标准的 OpenLDAP / Active Directory 目录树；
2. NAS 向该 Outpost 发起 simple_bind 或 search 时，Outpost 在底层将其翻译为对 authentik REST API 的凭据核验；
3. 管理员可以为该 LDAP 服务单独绑定 Flow，实现密码强度审计甚至通过邮件/推送静默触发动态授权。老旧应用无需更改任何代码，瞬间融入全局统一身份治理。

5. 身份即代码：Blueprints 声明式 GitOps

在现代 SRE 运维实践中，最忌讳通过 Web UI “点兵点将”手动配置生产环境。authentik 原生支持 Blueprints（蓝图）引擎，将所有 Flow、Stage、Policy、Application 以及 Provider 定义为版本受控的声明式 YAML。

5.1 声明式 YAML 蓝图语法

Blueprints 引入了强大的自定义 YAML Tag，能够在声明阶段安全引用关联模型的主键与唯一键：

version: 1
metadata:
  name: "GitOps - 生产环境堡垒机鉴权流水线"

entries:
  # 1. 声明一个密码核验阶段，关联内部数据库与 LDAP
  - model: authentik_stages_password.passwordstage
    identifiers:
      name: "prod-bastion-password-stage"
    attrs:
      backends:
        - authentik.core.auth.InbuiltBackend
        - authentik.sources.ldap.auth.LDAPBackend

  # 2. 声明一个 WebAuthn 硬件密匙核验阶段
  - model: authentik_stages_authenticator_validate.authenticatorvalidatestage
    identifiers:
      name: "prod-bastion-fido2-validate-stage"
    attrs:
      device_classes:
        - webauthn

  # 3. 声明认证 Flow
  - model: authentik_flows.flow
    id: flow_bastion_auth
    identifiers:
      slug: "prod-bastion-auth-flow"
    attrs:
      name: "生产堡垒机严格多因子流程"
      designation: "authentication"
      title: "Zero Trust Bastion Access"

  # 4. 建立流程与阶段的绑定 (FlowStageBinding)
  - model: authentik_flows.flowstagebinding
    identifiers:
      target: !KeyOf flow_bastion_auth
      stage: !Find [authentik_stages_password.passwordstage, [name, "prod-bastion-password-stage"]]
      order: 10
    attrs:
      re_evaluate_policies: true

  - model: authentik_flows.flowstagebinding
    identifiers:
      target: !KeyOf flow_bastion_auth
      stage: !Find [authentik_stages_authenticator_validate.authenticatorvalidatestage, [name, "prod-bastion-fido2-validate-stage"]]
      order: 20

5.2 GitOps 闭环自动化

• 自动化同步：蓝图文件可以直接挂载至容器的 /blueprints/ 目录；
• 幂等生效：通过 authentik_blueprints.metaapplyblueprint 元操作，系统每次启动或监听到 Git 仓库 Webhook 变更时自动重放，已存在的资源执行 Patch 更新，缺失的资源自动创建，真正实现身份基础设施的 CI/CD 自动化交付。

6. 生产级私有化部署实战与网关联动

以下提供一套经过高并发与可用性验证的完整 Docker Compose 编排模板，以及配合 Traefik 的 Forward Auth 实战配置。

6.1 Docker Compose 生产编排架构

创建工作目录并在 docker-compose.yml 中定义拓扑：

version: '3.8'

services:
  postgresql:
    image: docker.io/library/postgres:16-alpine
    container_name: authentik-postgres
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: "ChangeThisPostgresPasswordSecurely123"
      POSTGRES_USER: "authentik"
      POSTGRES_DB: "authentik"

  redis:
    image: docker.io/library/redis:7-alpine
    container_name: authentik-redis
    command: --save 60 1 --loglevel warning
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping | grep PONG"]
      interval: 10s
      timeout: 3s
      retries: 5
    volumes:
      - ./data/redis:/data

  server:
    image: ghcr.io/goauthentik/server:latest
    container_name: authentik-server
    restart: unless-stopped
    command: server
    environment:
      AUTHENTIK_REDIS__HOST: "redis"
      AUTHENTIK_POSTGRESQL__HOST: "postgresql"
      AUTHENTIK_POSTGRESQL__USER: "authentik"
      AUTHENTIK_POSTGRESQL__NAME: "authentik"
      AUTHENTIK_POSTGRESQL__PASSWORD: "ChangeThisPostgresPasswordSecurely123"
      AUTHENTIK_SECRET_KEY: "GenerateA64CharRandomAlphaNumericKeyHereForSecurity"
    volumes:
      - ./data/media:/media
      - ./data/custom-templates:/templates
    ports:
      - "9000:9000"
      - "9443:9443"
    depends_on:
      postgresql:
        condition: service_healthy
      redis:
        condition: service_healthy

  worker:
    image: ghcr.io/goauthentik/server:latest
    container_name: authentik-worker
    restart: unless-stopped
    command: worker
    environment:
      AUTHENTIK_REDIS__HOST: "redis"
      AUTHENTIK_POSTGRESQL__HOST: "postgresql"
      AUTHENTIK_POSTGRESQL__USER: "authentik"
      AUTHENTIK_POSTGRESQL__NAME: "authentik"
      AUTHENTIK_POSTGRESQL__PASSWORD: "ChangeThisPostgresPasswordSecurely123"
      AUTHENTIK_SECRET_KEY: "GenerateA64CharRandomAlphaNumericKeyHereForSecurity"
    user: root
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./data/media:/media
      - ./data/certs:/certs
      - ./data/custom-templates:/templates
    depends_on:
      postgresql:
        condition: service_healthy
      redis:
        condition: service_healthy

[!TIP]
关于 Worker 挂载 Docker Socket 的说明：
authentik-worker 挂载 /var/run/docker.sock 仅在启用 “Docker 托管式 Outpost” 时必需（Worker 作为控制器根据界面指令拉起独立的 Outpost 容器）。若仅使用嵌入式（Embedded）前哨或独立手动部署，可安全移除该 Socket 挂载以获得最佳权限沙箱隔离。

6.2 Traefik 联动 Forward Auth 实战配置

在 Traefik 中，配置一条 forwardAuth 中间件，拦截访问内部监控系统（如 uptime.example.com）的请求：

# traefik/dynamic_conf.yml
http:
  middlewares:
    authentik-auth:
      forwardAuth:
        address: "http://authentik-server:9000/outpost.goauthentik.io/auth/traefik"
        trustForwardHeader: true
        authResponseHeaders:
          - "X-authentik-username"
          - "X-authentik-groups"
          - "X-authentik-email"
          - "X-authentik-name"

  routers:
    uptime-kuma-router:
      rule: "Host(`uptime.example.com`)"
      entryPoints:
        - "websecure"
      middlewares:
        - "authentik-auth"
      service: "uptime-kuma-svc"
      tls:
        certResolver: "letsencrypt"

  services:
    uptime-kuma-svc:
      loadBalancer:
        servers:
          - url: "http://uptime-kuma-app:3001"

当未登录用户在浏览器访问 https://uptime.example.com 时：

1. Traefik 提取 Cookie 并调用 authentik 的 /outpost.goauthentik.io/auth/traefik 端点；
2. Rust 代理核以低于 1 毫秒的极速从内存 Moka 缓存中未检索到有效会话，直接返回 HTTP 401 并向 Traefik 附带 Location: https://auth.example.com/if/flow/default-authentication-flow/?next=... 重定向头；
3. 用户在 authentik 完成完整的 Flow 认证链条（含 WebAuthn 验证）后，带回全局加密 Session 凭证，重新访问即被 Traefik 顺畅放行，并将员工身份标头原样传递给后端容器。

7. 架构选型复盘：Keycloak、Authelia 与 authentik 三维对比

8. 结语

在云原生与零信任（Zero Trust）架构重构基础设施的今天，身份认证早已超越了单纯的“校验用户名和密码”。它演化为了承载网络安全防线第一道关卡、贯穿所有协议规范与终端设备的动态策略网格。

authentik 的成功，在于其既具备企业级 IAM 的协议包容度（SAML、OIDC、LDAP、RADIUS 一网打尽），又拥有极客工程的务实审美：

• 用 Flow-Stage 赋予了认证生命周期无限的组合可能；
• 用 Rust Axum 与 Hyper 锻造了坚不可摧的高并发网络代理底座；
• 用 Outpost 网格与 Blueprints 填平了中心调度与边缘隔离区、图形操作与 GitOps 自动化之间的鸿沟。

对于正在苦于身份孤岛蔓延、受制于 Keycloak 沉重资源开销或止步于 Authelia 协议局限的架构师与系统工程师而言，深入实践并引入 authentik，无疑是构筑现代化私有统一身份中枢的一剂良方。