使用 Cloudflare Access 锁定我们自托管的内部工具
在 ente，我们自己托管了一堆开源工具。虽然我们需要付出一些努力来设置和维护这些，但它有助于减少我们与第三方共享的数据量。我们使用 Sentry 进行错误报告，使用 Grafana 进行监控，使用 Metabase 进行产品指标（帮助像我这样不会说 SQL 的人）。
虽然我们有适当的系统来保护这些服务的凭据，但我们希望引入额外的进入障碍。显而易见的答案是将这些服务的可见性限制在内部网络中。但是查看Wireguard 的登录页面让我意识到我们需要一个全职的开发运维人员来走这条路。
我开始想知道“Cloudflare 怎么还没有解决这个问题”，并决定挖掘他们的网站迷宫。而且duh-doy，他们确实已经解决了这个问题。
简而言之，零信任访问会在您的端点前面放置一个登录页面，该页面对用户进行身份验证（跨多种向量），并将结果存储在 cookie 中，然后从那里随每个后续请求传递给 Cloudflare。
开箱即用地提供了带有“一次性 PIN”的电子邮件验证，它可以与特定于域的规则相结合，作为起点。
在我们的案例中，将 Github 添加为身份验证向量也是有意义的，其中包含验证用户在我们组织中的存在的规则。
我们继续将我们所有的内部工具放在 Access 后面，一切看起来都很笨拙。
直到。
我们意识到这破坏了向 Sentry 报告的错误。由于新实施的身份验证要求，来自客户端的所有报告错误的POST请求开始失败。
为了解决这个问题，Cloudflare 提供了Service Authentication 。这只是一种奇特的说法，“在标题中将这些秘密传递给我们，我们会让你通过”。我们设置了一个 Cloudflare Worker 作为代理来为我们附加这些标头，并将 Sentry SDK 配置为使用这个 Worker 作为隧道，从那以后一切都很好。
我们发现零信任访问是一种保护内部端点的简单方法。后来我们了解到，谷歌也与Beyond Corp合作了一段时间。
如果您对我们可以做得更好有更多见解，请写信给我们[email protected] 。如果您只是想关注我们与开发者的约会，请在Twitter 上关注我们，或者在Discord上打个招呼。