Subscribe to receive notifications of new posts:

2023 年 1 月 24 日的 Cloudflare 事件

01/25/2023

17 min read
Cloudflare incident on January 24, 2023

2023 年 1 月 24 日,由于负责管理服务令牌的发布代码出现错误,Cloudflare 的若干项服务在 121 分钟内无法使用。该事件致使 Cloudflare 的一系列产品性能下降,包括我们的 Workers 平台、Zero Trust 解决方案和内容分发网络 (CDN) 中的控制平面功能方面。

Cloudflare 提供了一个服务令牌功能,允许自动化服务对其他服务进行认证。客户可以使用服务令牌来确保在数据中心运行的应用程序和公共云提供商的资源之间的互动,例如,作为发布的一部分,我们打算引入一个功能,即向管理员显示令牌最后被使用的时间,使用户能够安全地清理未使用的令牌。这一变化无意中覆盖了关于服务令牌的其他元数据,使受影响账户的令牌在事件发生期间失效。

本次发布之所以影响其他服务,是因为 Cloudflare 在 Cloudflare 上运行。服务令牌影响账户的认证能力,其中两个受影响的账户为多个 Cloudflare 服务提供支持。当这些账户的服务令牌被覆盖后,在这些账户上运行的服务开始出现请求失败和其他意外错误。

虽然有限的细分客户和最终用户直接受到了本次事件的影响,并且其他客户服务可能出现了下降,但对 Cloudflare 的网络和服务的总体影响并不严重。尽管如此,我们深知这对于受影响的客户来说是很不愉快的体验。我们正在记录出错的原因以便您了解为什么会发生这种情况以及我们为防止这种情况再次发生所采取的措施。

什么是服务令牌?

当用户登录到一个应用程序或标识提供程序时,通常会输入用户名和密码。密码证明了该用户的用户名控制权,并且该服务应当允许用户继续下一步。可以添加额外的身份验证层,如硬件密钥或设备态势,但工作流程包括个人向服务证明他们的真实身份。

然而,个人并不是唯一需要对服务进行身份验证的用户。应用程序经常需要与其他应用程序交换信息。例如,设想您创建了一个应用程序,向用户展示他们即将到来的旅游计划的信息。

航空公司在自己的系统中存有关于航班及其飞行时长的详细信息。他们无意在互联网上公开每个人的详细旅游信息,也无意邀请您的应用程序加入他们的专用网络。同样,酒店希望确保他们只向有效的、经批准的第三方服务发送有关房间预订的详细信息。

您的应用程序需要一个可信任的方式来验证这些外部系统。服务令牌可通过作为您的服务的一种用户名和密码来解决这个问题。像用户名和密码一样,服务令牌分为两部分:一个客户端ID和一个客户端密钥。ID和密钥都必须和身份验证请求一起发送。令牌也被分配了一个期限,过了这个期限就会失效且必须对令牌进行轮换。您可以授予您的应用程序一个服务令牌,如果您需要的上游系统对其进行了验证,您的服务即可获取航空公司和酒店信息,并在联合报告中呈现给终端用户。

当管理员创建 Cloudflare 服务令牌时,我们会生成客户端 ID 和客户端密钥对。然后,客户可以配置他们的请求服务,当他们需要访问受保护的资源时,将 ID 和密钥对作为 HTTP 标头发送。请求服务可以在任何环境中运行,包括在 Cloudflare 的网络内部以 Workers 形式或在一个单独的位置,如公共云提供商。客户需要在 Cloudflare 的反向代理后面部署相应的受保护资源。我们的网络会检查每个与已配置服务绑定的请求的 HTTP 标头。如果存在,Cloudflare 会验证其真实性,并阻止该请求或允许其继续。我们还会记录身份验证事件。

事件时间线

所有时间均为格林威治时间 (UTC)

在 2023 年 1 月 24 日下午 4 点 55 分,Access 工程团队启动了发布工作,无意中开始覆盖服务令牌元数据,从而导致了本次事件的发生。

在 2023 年 1 月 24 日下午 5 点 05 分,Access 工程团队的一名成员注意到了一个不相关的问题,并回滚了该软件版本,停止了对服务令牌元数据的进一步覆盖。

在服务令牌本身被更新之前,服务令牌的值不会在 Cloudflare 的网络中被更新(更多细节见下文)。这对于元数据被覆盖的服务令牌造成了交错影响。

2023 年 1 月 24 日下午 5 点 50 分:Cloudflare WARP 的第一个无效服务令牌被同步到我们的全局网络。开始对 WARP 和 Zero Trust 用户产生影响。

WARP 设备态势上传下降到零,引发内部警报

在 2023 年 1 月 24 日下午 6 点 12 分,由于 WARP 设备态势成功上传的大幅下降,宣布发生事件。

2023 年 1 月 24 日下午 6 点 19 分:Cloudflare API 的第一个无效服务令牌被同步到我们的全局网络。开始对 Cache Purge、Cache Reserve、Images 和 R2 产生影响。对这些产品触发了警报,确定了事件的更大范围。

在 2023 年 1 月 24 日下午 6 点 21 分,于初步调查中发现了被覆盖的服务令牌。

在 2023 年 1 月 24 日下午 6 点 28 分,本次事件等级被提升至涵盖所有受影响的产品。

在 2023 年 1 月 24 日下午 6 点 51 分,确定并实施了一个初步解决方案,将 Cloudflare WARP 帐户的服务令牌恢复至其原始值,对 WARP 和 Zero Trust 产生影响。对 WARP 和 Zero Trust 的影响结束。

在 2023 年 1 月 24 日下午 6 点 56 分,在 Cloudflare API 帐户上实施了相同的解决方案,对 Cache Purge、Cache Reserve、Images 和 R2 产生影响。对 Cache Purge、Cache Reserve、Images 和 R2 的影响结束。

在 2023 年 1 月 24 日下午 7 点 00 分,对 Cloudflare API 账户进行了更新,该更新错误地覆盖了 Cloudflare API 账户。重新对 Cache Purge、Cache Reserve、Images 和 R2 产生影响。所有内部 Cloudflare 账户更改随后被锁定,直到事件解决。

在 2023 年 1 月 24 日下午 7 点 07 分,Cloudflare API 已被更新,其涵盖了正确的服务令牌值。对 Cache Purge、Cache Reserve、Images 和 R2 的影响结束。

在 2023 年 1 月 24 日下午 7 点 51 分,所有受影响的账户都从数据库备份中恢复了其服务令牌。事件结束。

发布的是什么,以及错误是如何发生的?

Access 团队正在推出一种新的对服务令牌的修改,增加了“最后一次见到的时间”字段。这是一个常用的功能请求,以帮助识别哪些服务令牌处于活跃使用状态。

出现什么错误了?

”最后一次见到的时间”值是通过扫描账户登录事件Kafka队列中的所有新登录事件得出的。如果检测到使用服务令牌的登录事件,则启动对相应的服务令牌的最后看到的值的更新。

为了更新服务令牌的“最后一次见到的时间“值,要进行读写交易以收集相应服务令牌的信息。出于安全性原因,服务令牌读取请求默认会编辑“客户端密钥”值。然后,对服务令牌的“最后一次见到的时间”更新使用了读取的信息,其不包括“客户端密钥”,并在写入时使用一个空的“客户端密钥”来更新服务令牌。

下面是一个正确和不正确服务令牌值的示例:

Access 服务令牌值示例

{
  "1a4ddc9e-a1234-4acc-a623-7e775e579c87": {
    "client_id": "6b12308372690a99277e970a3039343c.access",
    "client_secret": "<hashed-value>", <-- 您的期望值
    "expires_at": 1698331351
  },
  "23ade6c6-a123-4747-818a-cd7c20c83d15": {
    "client_id": "1ab44976dbbbdadc6d3e16453c096b00.access",
    "client_secret": "", <--- 问题所在
    "expires_at": 1670621577
  }
}

服务令牌“客户端密钥”数据库确实有一个“非空”检查,但是在这种情况下,一个空的文本字符串并没有触发为空值。

由于这个错误,任何在“最后一次见到的时间”发布的 10 分钟内使用服务令牌进行认证的 Cloudflare 账户,其“客户端密钥”值都会被设置为一个空字符串。然后需要修改服务令牌,以便将空的“客户端密钥”用于身份验证。共有 4 个账户处于这种状态,它们均为 Cloudflare 的内部账户。

我们是如何解决问题的?

作为一个临时解决方案,我们能够为那些服务令牌被覆盖的账户手动恢复正确的服务令牌值。这阻止了对受影响的 Cloudflare 服务所造成的直接影响。

数据库团队随后能够实施一个解决方案,从一个较旧的数据库副本中恢复所有受影响账户的服务令牌。这样即可结束本次事件所造成的影响。

这为什么会影响到其他 Cloudflare 服务?

服务令牌影响账户的认证能力。其中两个受影响的账户为多个 Cloudflare 服务提供支持。当这些账户的服务令牌被覆盖后,在这些账户上运行的服务开始出现请求失败和其他意外错误。

Cloudflare WARP 注册

Cloudflare 提供了一个移动和桌面前向代理,Cloudflare WARP(我们的“1.1.1.1”应用程序),任何用户都可以在设备上安装,以提高其互联网流量的隐私性。任何个人无需 Cloudflare 账户即可安装这项服务,我们不对可将活动映射到用户的日志进行保留。

当用户使用 WARP 进行连接时,Cloudflare 通过依靠用于接收和验证设备上的密钥的服务来验证设备的注册情况。反过来,该服务会与另一个系统进行通信,以告知我们的网络为新注册的设备提供对网络的访问

在这一事件中,注册服务无法再与我们网络中用于验证设备的系统进行通信。因此,用户无法再注册新设备和/或在新设备上安装应用程序,而且可能遇到了关于升级到新版本应用程序的问题(这也会触发重新注册)。

Cloudflare Zero Trust 设备态势和重新验证政策

Cloudflare 提供了一个全面的 Zero Trust 解决方案,客户可以在已添加或尚未添加设备代理的情况下进行部署。有些使用案例只有在设备上使用 Cloudflare 代理时才可用。该代理是同一个 Cloudflare WARP 解决方案的企业版本,在任何需要发送或接收设备状态的时候都出现了类似的功能降级。这影响了 Cloudflare Zero Trust 的三个使用案例。

首先,与消费者产品类似,新设备无法注册,现有设备无法撤销。管理员也无法修改已注册设备的设置。在所有情况下,错误都会呈现给用户。

其次,许多使用 Cloudflare 的 Zero Trust 解决方案替换现有专用网络的客户可能会添加一些规则,通过使用会话持续时间策略不断验证用户身份。这些规则的目的是强制用户重新验证,以防止过时的会话对内部系统的持续访问。设备上的代理会根据来自 Cloudflare 控制平面的信号来提示用户重新验证。在事件发生期间,信号没有被发送,用户无法成功进行重新验证。

最后,依赖设备态势规则的客户也受到了影响。设备态势规则允许使用 Access 或 Gateway 策略的客户依靠 WARP 代理来持续遵循“设备符合企业合规规则”。

代理将这些信号传达给负责维护设备状态的 Cloudflare 服务。Cloudflare 的 Zero Trust 访问控制产品使用服务令牌来接收这一信号,并与其他规则共同对其进行评估,以确定用户是否可以访问某一特定资源。在本次事件中,这些规则默认为阻止行动,这意味着经这些政策修改后的流量对用户来说是打了折扣的。在某些情况下,这意味着来自一个设备的所有互联网流量被完全阻断,使用户无法访问任何信息。

Cloudflare Gateway 每5分钟为用户缓存一次设备态势状态,以应用 Gateway 策略。设备态势状态被缓存,因此 Gateway 可以应用策略,而不必在每次请求时都验证设备状态。根据所匹配的网关策略类型,用户将面临两种不同的结果。如果与网络策略相匹配,用户将面临连接中断的情况,而对于 HTTP 策略,会出现一个 5XX 错误页面。在事件得到解决之前,峰值超过了 5 万个 5XX 错误/分钟,并且有超过 1050 万个态势读取错误。

网关 5XX 错误/分钟

网关设备态势错误总数

Cloudflare R2 Storage 和 Cache Reserve

Cloudflare R2 Storage 允许开发人员存储大量的非结构化数据,而无需支付与典型云存储服务相关的昂贵的出口带宽费用。

在本次事件中,R2 服务无法向 Cloudflare 基础结构的其他部分提出出站 API 请求。因此,R2 用户在向 R2 提出请求时会面临较高的请求失败率。

许多 Cloudflare 产品也依赖 R2 进行数据存储并受到了影响。例如,Cache Reserve 用户在这个窗口期受到影响,会面临不在主缓存中的项目的源负载增加的情况。在这次事件中,对 Cache Reserve 服务的大部分读写操作都受到影响,导致 Cache Reserve 的输入输出失败。然而,当 Cache Reserve 面临 R2 错误时,将回退为客户源,所以用户流量服务在这一时期仍然得以运行。

Cloudflare 缓存清除

Cloudflare 的内容分发网络 (CDN) 将作为互联网资产的内容缓存在我们世界各地的数据中心的网络中,以缩短用户请求为获得响应所传输的距离。在某些情况下,客户希望清除我们缓存的内容,用不同的数据进行取代。

Cloudflare 控制平面是管理员与我们的网络进行交互的地点,它使用服务令牌来验证并实现缓存清除服务。在本次事件中,许多清除请求失败,同时服务令牌失效。我们看到了 20 个清除请求失败/秒和高达 70 个请求/秒的平均影响。

我们会采取什么措施来防止这种情况再次发生?

我们严肃地对待这一事件,并认识到它所产生的影响。我们已经确定了几项措施,以应对日后出现类似问题的风险。作为对这一事件的回应,我们将实施以下补救计划:

测试:Access 工程团队将添加单元测试,即在推出任何新功能之前,自动发现任何类似的服务令牌覆盖问题。

警报:对于失败的服务令牌身份验证请求的急剧增加,Access 团队将实施自动警报,以便在问题全面造成影响之前发现问题。

流程:Access 团队已经确定了流程改进,以允许加快特定数据库表的回滚速度。

实施:所有相关的数据库字段将被更新,以便在现有的“非空检查”的基础上加入对空字符串的检查

对于本次事件给客户访问许多 Cloudflare 服务时所造成的影响,我们感到抱歉。我们正在积极实施这些改进,以确保未来改进后的稳定性,并确保这个问题不会再次发生。

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
Outage (JP)Post Mortem (CN)简体中文

Follow on X

Kenny Johnson|@KennyJohnsonATX
Cloudflare|@cloudflare

Related posts

April 29, 2024 1:00 PM

2024年第1四半期インターネットの障害のまとめ

2024年の第1四半期は、かなりの数のインターネットの中断を見て幕を開けました。複数のネットワークプロバイダーにまたがる加入者の接続を妨げる技術的な問題の中に、RPKI、DNS、DNSSECの問題があったことが最も関心の的となり得ます...

January 22, 2024 2:00 PM

2023年第4四半期インターネットの障害のまとめ

この記事では、2023年第4四半期にCloudflareが観測したインターネット上の混乱を、Cloudflare Radarやその他のCloudflare内部ツールからのトラフィックグラフで裏付け、関連する原因や共通の地域ごとにグループ分けしてレビューします...

December 12, 2023 2:00 PM

Cloudflare 2023年版Year in Review(1年の振り返り)

このCloudflare Radarの2023年版Year in Review(1年の振り返り)は、Cloudflareのネットワークデータを基に、様々なトラフィック、接続性、速度に関する情報をまとめ、世界および国・地域レベルで1年を通して観察されたインターネットの傾向とパターンをレビューした4回目の年次報告書です...