之前短暂用过 Cloudflare Access 的东西，后来觉得麻烦就不用了，但是最近接触到一个项目，需要用户登陆，但是居然连最基本的鉴权都没有，如果被扫到的话 Token 之类的都被泄漏了

我并不想做过多的修改，这时候就又想起了 Cloudflare Access

GPT 说什么是 Cloudflare Access

Cloudflare Access 是 Cloudflare 提供的一项 Zero Trust 网络访问控制服务，主要用于保护企业或个人的 内部应用、后台系统或管理面板，不再依赖传统 VPN。

它的核心功能可以总结为：

🌐 什么是 Cloudflare Access？

Cloudflare Access 是 Zero Trust 安全架构的一部分，允许你：

• 为任意 Web 应用（本地或云端）添加身份验证和访问控制
• 控制谁可以访问你的应用，即使这些应用部署在公网、私有网络或自建服务器上
• 取代传统 VPN，实现基于身份的细粒度控制

🔐 它是怎么工作的？

简化的工作流程如下：

1. 用户访问你保护的 Web 应用（比如 https://admin.example.com）
2. Cloudflare 拦截请求，检查是否已登录并授权
3. 如果没有登录，重定向用户进行 身份验证（支持 Google、GitHub、Azure AD、邮箱验证码等方式）
4. 验证通过后，根据你设定的访问策略决定是否允许进入应用

🧰 支持的功能和优势

• ✅ 支持主流身份提供商（Google, GitHub, SAML, OIDC 等）
• ✅ 支持设备姿态检查（比如设备是否开启杀毒软件、加密磁盘）
• ✅ 无需公网暴露真实服务器 IP（可与 Cloudflare Tunnel 结合使用）
• ✅ 提供详细的访问日志与审计功能
• ✅ 与 Cloudflare Gateway 和 WARP 联合使用，形成完整的 Zero Trust 网络防护方案

📌 适合哪些场景？

• 限制谁可以访问公司后台（如 WordPress 后台、内网管理平台）
• 保护开发环境、Grafana、Jupyter、Kibana 等敏感服务
• 不用 VPN 也能安全远程访问自建服务
• 设置某个子域只允许特定邮箱后缀（如 @yourcompany. Com）的人访问

🚀 示例：只允许公司邮箱访问后台

你可以很简单地设定一条策略：

"只允许使用 @mycompany.com 邮箱登录的用户访问 admin.example.com"

Cloudflare Access 会自动完成登录、授权流程，无需你手动维护用户列表或自己开发登录系统。

实战

Cloudflare Tunnel

我是将 Cloudflare Access 和 Cloudflare Tunnel 联合起来使用的，Cloudflare Tunnel 使得我无需暴露任何的端口和源 IP 在公网，即可实现公网访问

[Internet]
    │
[Cloudflare Access 控制]
    │
[Cloudflare Tunnel 连接器 cloudflared 容器]
    │
[Docker 网络]
 ├── wordpress: WordPress 应用
 └── mysql: 数据库

具体部署 Cloudflare Tunnel 的方法，网上有很多博主写了非常详细的教程，在这里我也懒得说了，但是绝大多数博主都会使用 Cloudflare CLI 本机部署，我一般习惯将 Cloudflare Tunnel 的容器和业务容器编排在一起，然后通过 docker- network 将其划为同一网络，举一个例子：

services:
  myapp:
    image: node:18
    command: bash -c "npx serve -s"  # 替换为你的实际启动命令
    ports:
      - "3000:3000"
    working_dir: /app
    volumes:
      - ./myapp:/app
    networks:
      - tunnel-net

  cloudflared:
    image: cloudflare/cloudflared:latest
    restart: always
    command: tunnel run
    environment:
      - TUNNEL_TOKEN=<你的-tunnel-token>
    networks:
      - tunnel-net

networks:
  tunnel-net:

这样的话，Cloudflare Tunnel 就和业务绑定在一起了，如果是使用 CLI 本机部署的话，污染环境是一方面，另一方面端口暴露也不好控制，docker-network 会强制修改 iptables 和 ufw 发生冲突，不太好配置防火墙

在服务类型这里，你可以借助 Docker 的 DNS 解析，直接写要反向代理的服务名，这样也避免了要去找 IP 的烦恼

Cloudflare Access

在实际使用之前，我们不如来了解一下 Cloudflare Access 的实现原理

你在 Cloudflare Zero Trust Dashboard 中，为某个 Tunnel 配置一个公共主机名（Public Hostname），比如你设置：

public hostname: admin.example.com
service: http://localhost:8000

表示本地端口 8000 服务将通过 admin.example.com 暴露出去

当我们启动 Cloudflare Access 时，你对这个子域设置一条 Access 策略：

• 只允许登录的用户访问
• 可以指定邮箱后缀、Google 账号、GitHub、Okta 等身份源
• 可启用设备校验、多因子认证等安全策略

只有符合上述条件的用户才能对这个页面进行访问，否则就会出现验证页面：

当受认证的用户完成授权后，才能正常登陆

保护你的站点

新建一个应用

会话持续时间类似于一个有时效性的 Cookie，实效过了就需要重新登陆，这里的公共主机名就是你要保护的站点，它必须托管到 Cloudflare，并且使用 Cloudflare 的 CDN，即 proxy，这样的话流量才会经过 Cloudflare 的边缘节点，才能帮你拦住请求

其中的 Access 策略的配置也挺重要的，它决定了谁能访问你的站点，其中的内容还挺多的，具体可以看一下文档：Access policies · Cloudflare Zero Trust docs

我设置了一个规则组，里面只有我一个，因此在这里选择 Rule Group，一般来说也可以限制域名或者其他的

之后点击确认即可

值得注意的是，Cloudflare 还提供了多种第三方的登陆方式，如果你想要使用的话，记得添加登陆方式之后将其添加到策略里面去，不然还是没法使用

总结

这套方案比较适合哪些人使用呢？比较适合需要将服务暴露到公网，但是服务本身的鉴权不够完整，或者存在漏洞，容易被爆破的场景，比如说群晖 NAS 或者我最近接触的这个项目

赛博大善人无需多言！