尧图网页设计 
如何配置 Dozzle 使用 Authelia 反向代理认证【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle如果你已经部署或打算部署Authelia并想让它完整接管 Dozzle 的登录认证——用户先在 Authelia 登录通过后才看得到容器日志——就需要把 Dozzle 切到forward-proxy认证模式。在这种模式下 Dozzle 不做任何登录只信任反向代理转发过来的请求头默认读取Remote-User、Remote-Email等由 Authelia 通过 forward-auth 中间件完成身份校验。本文以 Forward Proxy 文档中的 Authelia 示例为主线覆盖Dozzle 侧要设置的参数、Authelia 与 Traefik 的示例配置、把 Authelia 用户组映射为 Dozzle 角色以及如何判断配置是否生效。示例基于 Docker Compose Traefik 的组合且要求持有有效的 SSL 证书Authelia 只支持 SSL。1. 先理解 forward-proxy 模式的请求头设置--auth-provider为forward-proxy后Dozzle 期望收到以下请求头见 forward-proxy 文档Remote-User映射为 Dozzle 用户名例如johndoeRemote-Email用户邮箱同时用于查找 Gravatar 头像Remote-Name显示名例如John DoeRemote-Filter该用户允许使用的过滤器逗号分隔Remote-Roles该用户允许的角色逗号分隔。这些默认头名都可以通过环境变量调整见 环境变量表DOZZLE_AUTH_HEADER_USER、DOZZLE_AUTH_HEADER_EMAIL、DOZZLE_AUTH_HEADER_NAME、DOZZLE_AUTH_HEADER_FILTER、DOZZLE_AUTH_HEADER_ROLES。此外可用DOZZLE_AUTH_LOGOUT_URL配置一个登出地址文档示例值为http://oauth2.example.ru/oauth2/sign_out这是可选项不是必做步骤。一个必须遵守的前提forward-proxy 模式下绝不能把 Dozzle 端口直接发布出去。Authentication 总览明确指出Dozzle 对每个请求都信任Remote-User头且在没有 roles 头时会授予全部角色——如果 8080 端口直接暴露任何人都能绕过 Authelia 自己伪造头部。Dozzle 必须留在内部网络里只发布代理本文示例中即 Traefik。另外forward-proxy 模式下用户个人设置同样会写入磁盘所以要挂载/data卷否则容器重建后设置丢失。2. 部署配置Authelia Traefik Dozzle下面是 forward-proxy 文档给出的示例docker-compose.yml。其中authelia.example.com、dozzle.example.com、traefik.example.com是文档中的示例域名替换成你自己的域名时要保证 compose 的 Traefik 标签、Authelia 配置中的access_control域名和 cookie domain 三处一致networks: net: driver: bridge services: authelia: image: authelia/authelia container_name: authelia volumes: - ./authelia:/config networks: - net labels: - traefik.enabletrue - traefik.http.routers.authelia.ruleHost(authelia.example.com) - traefik.http.routers.authelia.entrypointshttps - traefik.http.routers.authelia.tlstrue - traefik.http.routers.authelia.tls.optionsdefault - traefik.http.middlewares.authelia.forwardAuth.addresshttp://authelia:9091/api/authz/forward-auth - traefik.http.middlewares.authelia.forwardAuth.trustForwardHeadertrue - traefik.http.middlewares.authelia.forwardAuth.authResponseHeadersRemote-User,Remote-Groups,Remote-Name,Remote-Email expose: - 9091 restart: unless-stopped traefik: image: traefik:v3.5 container_name: traefik volumes: - ./traefik:/etc/traefik - /var/run/docker.sock:/var/run/docker.sock networks: - net labels: - traefik.enabletrue - traefik.http.routers.api.ruleHost(traefik.example.com) - traefik.http.routers.api.entrypointshttps - traefik.http.routers.api.serviceapiinternal - traefik.http.routers.api.tlstrue - traefik.http.routers.api.tls.optionsdefault - traefik.http.routers.api.middlewaresautheliadocker ports: - 80:80 - 443:443 command: - --api - --providers.dockertrue - --providers.docker.exposedByDefaultfalse - --providers.file.filename/etc/traefik/certificates.yml - --entrypoints.httptrue - --entrypoints.http.address:80 - --entrypoints.http.http.redirections.entrypoint.tohttps - --entrypoints.http.http.redirections.entrypoint.schemehttps - --entrypoints.httpstrue - --entrypoints.https.address:443 - --logtrue - --log.levelDEBUG dozzle: image: amir20/dozzle:latest networks: - net environment: DOZZLE_AUTH_PROVIDER: forward-proxy volumes: - /var/run/docker.sock:/var/run/docker.sock - dozzle:/data labels: - traefik.enabletrue - traefik.http.routers.dozzle.ruleHost(dozzle.example.com) - traefik.http.routers.dozzle.entrypointshttps - traefik.http.routers.dozzle.tlstrue - traefik.http.routers.dozzle.tls.optionsdefault - traefik.http.routers.dozzle.middlewaresautheliadocker expose: - 8080 restart: unless-stopped volumes: dozzle:这个 compose 里对当前场景起决定作用的三处Dozzle 服务DOZZLE_AUTH_PROVIDER: forward-proxy开启代理认证模式expose: 8080而不使用ports让 8080 只存在于 compose 网络内外部只能经过 Traefik Authelia 到达 Dozzle。Authelia 的 forwardAuth 中间件指向http://authelia:9091/api/authz/forward-auth并在authResponseHeaders中指定 Authelia 校验通过后回传给下游的头Remote-User,Remote-Groups,Remote-Name,Remote-Email。注意这里回传的是Remote-Groups而不是Remote-Roles下一节会处理这个差异。Dozzle 的路由挂载了autheliadocker中间件所有访问dozzle.example.com的请求先经 Authelia 鉴权通过后带着上述头部转发给 Dozzle。如果不使用 Compose也可以用 CLI 启动 Dozzleforward-proxy 文档给出的形式docker run -v /var/run/docker.sock:/var/run/docker.sock -v /path/to/dozzle/data:/data -p 8080:8080 amir20/dozzle --auth-provider forward-proxy注意裸docker run时请自行保证-p 8080:8080只对内网发布并让代理Authelia 所在的代理层注入同样的请求头安全边界与 Compose 示例的要求一致。Authelia 侧的示例配置文档说明 Authelia 本身的安装配置不在该节范围内但提供了一份可参考的configuration.yml示例放在 compose 中./authelia:/config挂载目录下。其中access_control对dozzle.example.com使用one_factor策略单因子认证即可放行default_policy为denyserver: address: tcp://0.0.0.0:9091 log: level: info totp: issuer: authelia.com identity_validation: reset_password: jwt_secret: a_very_important_secret authentication_backend: file: path: /config/users_database.yml access_control: default_policy: deny rules: - domain: traefik.example.com policy: one_factor - domain: dozzle.example.com policy: one_factor session: secret: unsecure_session_secret cookies: - domain: example.com # Should match whatever your root protected domain is authelia_url: https://authelia.example.com default_redirection_url: https://public.example.com regulation: max_retries: 3 find_time: 120 ban_time: 300 storage: encryption_key: you_must_generate_a_random_string_of_more_than_twenty_chars_and_configure_this local: path: /config/db.sqlite3 notifier: filesystem: filename: /config/notification.txt上面的jwt_secret、session.secret、encryption_key均为文档原样的示例值文档注释也提示 encryption_key 需自行生成二十字符以上的随机串落地部署时应替换为自己的值cookies.domain按注释要求替换为你的受保护根域名。用户列表由 Authelia 的users_database.ymlfile后端管理这部分属于 Authelia 自身配置Dozzle 不读取也不管理。3. 把 Authelia 用户组映射为 Dozzle 角色Authelia 通过Remote-Groups头下发用户所属组而 Dozzle 默认读取Remote-Roles——两者对不上。forward-proxy 文档给出的做法是在 Dozzle 服务上设置DOZZLE_AUTH_HEADER_ROLES: Remote-Groups并把 Authelia 的组名直接命名为 Dozzle 角色名。Dozzle 为此提供了dozzle_前缀别名例如名为dozzle_shell的组授予shell角色其他不带该前缀、也非内置角色名的组名会被忽略。加到 dozzle 服务后environment: DOZZLE_AUTH_PROVIDER: forward-proxy DOZZLE_AUTH_HEADER_ROLES: Remote-Groups完整的角色定义见 Simple Authentication 文档的角色表shell打开 exec 会话实例需同时开启--enable-shell、actions启停容器需--enable-actions、download、notifications、cloud、allroles为空时的默认值、none。两个需要明确知道的边界不做这个映射时每个已认证用户都会获得全部角色——forward-proxy 文档明确说明 Without that mapping every authenticated user gets all roles。如果所有用户本来就应当拥有全部权限可以接受这个默认行为但建议显式确认。notifications与cloud是实例级权限规则按表达式匹配容器、不受用户 filter 限制云连接也是单实例单 API key。文档建议只授予信任全部容器的用户。4. 结果验证与常见现象配置完成后按文档描述的机制判断是否生效访问 Dozzle 域名示例中的dozzle.example.com。由于路由挂了autheliadocker中间件且策略是one_factor未登录请求会被拦到 Authelia 的登录页登录成功后带着Remote-User、Remote-Name、Remote-Email以及Remote-Groups回到 Dozzle。登录后的 Dozzle 界面中用户名、显示名来自Remote-User/Remote-Name头像按Remote-Email查找 Gravatar——页面上显示的是你自己的信息说明头部链路是通的。角色方面若你已设置DOZZLE_AUTH_HEADER_ROLES: Remote-Groups并按dozzle_*命名了组未拥有对应组的用户将看不到相应操作入口若没有配置该环境变量则所有认证用户拥有全部角色见上节。用户个人设置应持久化在挂载的dozzle:/data卷中重建容器不丢失。与当前配置直接相关的已知问题来自 Reverse Proxy Base Path 文档的常见坑和 Authentication 总览Authelia 无法启动/证书报错文档明确 Authelia only supports SSL必须配置有效的 SSL 证书。日志在几秒后停更或成批到达Dozzle 用 SSE 推送日志代理缓冲会打断它。若启用过 Traefik 的compress中间件需要排除text/event-stream文档给出的 Traefik 写法见 changing-base 页若日志只停几秒多为代理读/写超时过短文档建议把超时提高到至少几分钟Nginx 示例为proxy_read_timeout 3600s。Shell 立刻断开WebSocket 升级头没有被转发Traefik 会自动处理 WebSocket 升级但自行配置代理时需确认转发了Upgrade与Connection头。绕过认证如果哪天发现没登录也能打开 Dozzle先检查是否把 Dozzle 的 8080 端口发布到了外部——forward-proxy 模式下这是最典型的配置错误Dozzle 会无条件信任请求里的Remote-User。5. 可选配置登出地址如果需要 Dozzle 内显示一个指向 Authelia 的登出入口可以在 dozzle 服务上增加DOZZLE_AUTH_LOGOUT_URL: https://authelia.example.com/logout文档中的示例值为http://oauth2.example.ru/oauth2/sign_out此处应按你的 Authelia 实际登出端点设置不配置时 Dozzle 不提供登出链接但这不影响日志查看功能。完成以上配置后Dozzle 的所有访问都必须经过 Authelia 的 forward-auth 校验Dozzle 自身不再出现登录页用户身份与角色完全由 Authelia 的组和Remote-Groups头决定。进一步的用户管理增删用户、组在 Authelia 侧的users_database.yml中进行Dozzle 侧无需再维护users.yml。【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何配置 Dozzle 使用 Authelia 反向代理认证？
如何配置 Dozzle 使用 Authelia 反向代理认证【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle如果你已经部署或打算部署Authelia并想让它完整接管 Dozzle 的登录认证——用户先在 Authelia 登录通过后才看得到容器日志——就需要把 Dozzle 切到forward-proxy认证模式。在这种模式下 Dozzle 不做任何登录只信任反向代理转发过来的请求头默认读取Remote-User、Remote-Email等由 Authelia 通过 forward-auth 中间件完成身份校验。本文以 Forward Proxy 文档中的 Authelia 示例为主线覆盖Dozzle 侧要设置的参数、Authelia 与 Traefik 的示例配置、把 Authelia 用户组映射为 Dozzle 角色以及如何判断配置是否生效。示例基于 Docker Compose Traefik 的组合且要求持有有效的 SSL 证书Authelia 只支持 SSL。1. 先理解 forward-proxy 模式的请求头设置--auth-provider为forward-proxy后Dozzle 期望收到以下请求头见 forward-proxy 文档Remote-User映射为 Dozzle 用户名例如johndoeRemote-Email用户邮箱同时用于查找 Gravatar 头像Remote-Name显示名例如John DoeRemote-Filter该用户允许使用的过滤器逗号分隔Remote-Roles该用户允许的角色逗号分隔。这些默认头名都可以通过环境变量调整见 环境变量表DOZZLE_AUTH_HEADER_USER、DOZZLE_AUTH_HEADER_EMAIL、DOZZLE_AUTH_HEADER_NAME、DOZZLE_AUTH_HEADER_FILTER、DOZZLE_AUTH_HEADER_ROLES。此外可用DOZZLE_AUTH_LOGOUT_URL配置一个登出地址文档示例值为http://oauth2.example.ru/oauth2/sign_out这是可选项不是必做步骤。一个必须遵守的前提forward-proxy 模式下绝不能把 Dozzle 端口直接发布出去。Authentication 总览明确指出Dozzle 对每个请求都信任Remote-User头且在没有 roles 头时会授予全部角色——如果 8080 端口直接暴露任何人都能绕过 Authelia 自己伪造头部。Dozzle 必须留在内部网络里只发布代理本文示例中即 Traefik。另外forward-proxy 模式下用户个人设置同样会写入磁盘所以要挂载/data卷否则容器重建后设置丢失。2. 部署配置Authelia Traefik Dozzle下面是 forward-proxy 文档给出的示例docker-compose.yml。其中authelia.example.com、dozzle.example.com、traefik.example.com是文档中的示例域名替换成你自己的域名时要保证 compose 的 Traefik 标签、Authelia 配置中的access_control域名和 cookie domain 三处一致networks: net: driver: bridge services: authelia: image: authelia/authelia container_name: authelia volumes: - ./authelia:/config networks: - net labels: - traefik.enabletrue - traefik.http.routers.authelia.ruleHost(authelia.example.com) - traefik.http.routers.authelia.entrypointshttps - traefik.http.routers.authelia.tlstrue - traefik.http.routers.authelia.tls.optionsdefault - traefik.http.middlewares.authelia.forwardAuth.addresshttp://authelia:9091/api/authz/forward-auth - traefik.http.middlewares.authelia.forwardAuth.trustForwardHeadertrue - traefik.http.middlewares.authelia.forwardAuth.authResponseHeadersRemote-User,Remote-Groups,Remote-Name,Remote-Email expose: - 9091 restart: unless-stopped traefik: image: traefik:v3.5 container_name: traefik volumes: - ./traefik:/etc/traefik - /var/run/docker.sock:/var/run/docker.sock networks: - net labels: - traefik.enabletrue - traefik.http.routers.api.ruleHost(traefik.example.com) - traefik.http.routers.api.entrypointshttps - traefik.http.routers.api.serviceapiinternal - traefik.http.routers.api.tlstrue - traefik.http.routers.api.tls.optionsdefault - traefik.http.routers.api.middlewaresautheliadocker ports: - 80:80 - 443:443 command: - --api - --providers.dockertrue - --providers.docker.exposedByDefaultfalse - --providers.file.filename/etc/traefik/certificates.yml - --entrypoints.httptrue - --entrypoints.http.address:80 - --entrypoints.http.http.redirections.entrypoint.tohttps - --entrypoints.http.http.redirections.entrypoint.schemehttps - --entrypoints.httpstrue - --entrypoints.https.address:443 - --logtrue - --log.levelDEBUG dozzle: image: amir20/dozzle:latest networks: - net environment: DOZZLE_AUTH_PROVIDER: forward-proxy volumes: - /var/run/docker.sock:/var/run/docker.sock - dozzle:/data labels: - traefik.enabletrue - traefik.http.routers.dozzle.ruleHost(dozzle.example.com) - traefik.http.routers.dozzle.entrypointshttps - traefik.http.routers.dozzle.tlstrue - traefik.http.routers.dozzle.tls.optionsdefault - traefik.http.routers.dozzle.middlewaresautheliadocker expose: - 8080 restart: unless-stopped volumes: dozzle:这个 compose 里对当前场景起决定作用的三处Dozzle 服务DOZZLE_AUTH_PROVIDER: forward-proxy开启代理认证模式expose: 8080而不使用ports让 8080 只存在于 compose 网络内外部只能经过 Traefik Authelia 到达 Dozzle。Authelia 的 forwardAuth 中间件指向http://authelia:9091/api/authz/forward-auth并在authResponseHeaders中指定 Authelia 校验通过后回传给下游的头Remote-User,Remote-Groups,Remote-Name,Remote-Email。注意这里回传的是Remote-Groups而不是Remote-Roles下一节会处理这个差异。Dozzle 的路由挂载了autheliadocker中间件所有访问dozzle.example.com的请求先经 Authelia 鉴权通过后带着上述头部转发给 Dozzle。如果不使用 Compose也可以用 CLI 启动 Dozzleforward-proxy 文档给出的形式docker run -v /var/run/docker.sock:/var/run/docker.sock -v /path/to/dozzle/data:/data -p 8080:8080 amir20/dozzle --auth-provider forward-proxy注意裸docker run时请自行保证-p 8080:8080只对内网发布并让代理Authelia 所在的代理层注入同样的请求头安全边界与 Compose 示例的要求一致。Authelia 侧的示例配置文档说明 Authelia 本身的安装配置不在该节范围内但提供了一份可参考的configuration.yml示例放在 compose 中./authelia:/config挂载目录下。其中access_control对dozzle.example.com使用one_factor策略单因子认证即可放行default_policy为denyserver: address: tcp://0.0.0.0:9091 log: level: info totp: issuer: authelia.com identity_validation: reset_password: jwt_secret: a_very_important_secret authentication_backend: file: path: /config/users_database.yml access_control: default_policy: deny rules: - domain: traefik.example.com policy: one_factor - domain: dozzle.example.com policy: one_factor session: secret: unsecure_session_secret cookies: - domain: example.com # Should match whatever your root protected domain is authelia_url: https://authelia.example.com default_redirection_url: https://public.example.com regulation: max_retries: 3 find_time: 120 ban_time: 300 storage: encryption_key: you_must_generate_a_random_string_of_more_than_twenty_chars_and_configure_this local: path: /config/db.sqlite3 notifier: filesystem: filename: /config/notification.txt上面的jwt_secret、session.secret、encryption_key均为文档原样的示例值文档注释也提示 encryption_key 需自行生成二十字符以上的随机串落地部署时应替换为自己的值cookies.domain按注释要求替换为你的受保护根域名。用户列表由 Authelia 的users_database.ymlfile后端管理这部分属于 Authelia 自身配置Dozzle 不读取也不管理。3. 把 Authelia 用户组映射为 Dozzle 角色Authelia 通过Remote-Groups头下发用户所属组而 Dozzle 默认读取Remote-Roles——两者对不上。forward-proxy 文档给出的做法是在 Dozzle 服务上设置DOZZLE_AUTH_HEADER_ROLES: Remote-Groups并把 Authelia 的组名直接命名为 Dozzle 角色名。Dozzle 为此提供了dozzle_前缀别名例如名为dozzle_shell的组授予shell角色其他不带该前缀、也非内置角色名的组名会被忽略。加到 dozzle 服务后environment: DOZZLE_AUTH_PROVIDER: forward-proxy DOZZLE_AUTH_HEADER_ROLES: Remote-Groups完整的角色定义见 Simple Authentication 文档的角色表shell打开 exec 会话实例需同时开启--enable-shell、actions启停容器需--enable-actions、download、notifications、cloud、allroles为空时的默认值、none。两个需要明确知道的边界不做这个映射时每个已认证用户都会获得全部角色——forward-proxy 文档明确说明 Without that mapping every authenticated user gets all roles。如果所有用户本来就应当拥有全部权限可以接受这个默认行为但建议显式确认。notifications与cloud是实例级权限规则按表达式匹配容器、不受用户 filter 限制云连接也是单实例单 API key。文档建议只授予信任全部容器的用户。4. 结果验证与常见现象配置完成后按文档描述的机制判断是否生效访问 Dozzle 域名示例中的dozzle.example.com。由于路由挂了autheliadocker中间件且策略是one_factor未登录请求会被拦到 Authelia 的登录页登录成功后带着Remote-User、Remote-Name、Remote-Email以及Remote-Groups回到 Dozzle。登录后的 Dozzle 界面中用户名、显示名来自Remote-User/Remote-Name头像按Remote-Email查找 Gravatar——页面上显示的是你自己的信息说明头部链路是通的。角色方面若你已设置DOZZLE_AUTH_HEADER_ROLES: Remote-Groups并按dozzle_*命名了组未拥有对应组的用户将看不到相应操作入口若没有配置该环境变量则所有认证用户拥有全部角色见上节。用户个人设置应持久化在挂载的dozzle:/data卷中重建容器不丢失。与当前配置直接相关的已知问题来自 Reverse Proxy Base Path 文档的常见坑和 Authentication 总览Authelia 无法启动/证书报错文档明确 Authelia only supports SSL必须配置有效的 SSL 证书。日志在几秒后停更或成批到达Dozzle 用 SSE 推送日志代理缓冲会打断它。若启用过 Traefik 的compress中间件需要排除text/event-stream文档给出的 Traefik 写法见 changing-base 页若日志只停几秒多为代理读/写超时过短文档建议把超时提高到至少几分钟Nginx 示例为proxy_read_timeout 3600s。Shell 立刻断开WebSocket 升级头没有被转发Traefik 会自动处理 WebSocket 升级但自行配置代理时需确认转发了Upgrade与Connection头。绕过认证如果哪天发现没登录也能打开 Dozzle先检查是否把 Dozzle 的 8080 端口发布到了外部——forward-proxy 模式下这是最典型的配置错误Dozzle 会无条件信任请求里的Remote-User。5. 可选配置登出地址如果需要 Dozzle 内显示一个指向 Authelia 的登出入口可以在 dozzle 服务上增加DOZZLE_AUTH_LOGOUT_URL: https://authelia.example.com/logout文档中的示例值为http://oauth2.example.ru/oauth2/sign_out此处应按你的 Authelia 实际登出端点设置不配置时 Dozzle 不提供登出链接但这不影响日志查看功能。完成以上配置后Dozzle 的所有访问都必须经过 Authelia 的 forward-auth 校验Dozzle 自身不再出现登录页用户身份与角色完全由 Authelia 的组和Remote-Groups头决定。进一步的用户管理增删用户、组在 Authelia 侧的users_database.yml中进行Dozzle 侧无需再维护users.yml。【免费下载链接】dozzleRealtime log viewer for containers. Supports Docker, Swarm and K8s.项目地址: https://gitcode.com/GitHub_Trending/do/dozzle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考