Plusieurs services Cloudflare sont restés indisponibles pendant 37 minutes le 30 octobre 2023. Cette interruption était due à la mauvaise configuration d'un outil de déploiement utilisé par Workers KV. Particulièrement frustrant, l'incident a été aggravé par la dépendance de Cloudflare envers sa propre suite de produits. Nous sommes profondément désolés des répercussions de ce dernier sur nos clients. Les lignes qui suivent décrivent ce qui s'est mal passé, la manière dont l'incident a été résolu et les travaux que nous mettons en œuvre pour nous assurer que cette situation ne se reproduise jamais.
Le service Workers KV est notre référentiel clé-valeur mondial et distribué. Les clients et les équipes de Cloudflare l'utilisent indifféremment pour gérer les données de configuration, les recherches de routage, les groupements de ressources statiques, les jetons d'authentification et les autres données qui nécessitent un accès à faible latence.
Au cours de l'incident, KV a renvoyé ce qu'il pensait être un code d'état HTTP 401 Unauthorized (Échec de l'authentification) valide au lieu de la ou des paires clé-valeur demandées en raison d'un bug au niveau d'un nouvel outil de déploiement utilisé par le référentiel.
Ces erreurs se sont manifestées différemment pour chaque produit, en fonction de la manière dont KV est utilisé par chaque service. Les effets de l'incident sont décrits ci-dessous.
Les fonctions touchées
Un certain nombre de services Cloudflare dépendent de Workers KV pour la distribution de leur configuration, de leurs informations de routage, de leurs ressources statiques et de leur état d'authentification à travers le monde. Plutôt que de recevoir la réponse appropriée à l'exécution d'une opération de récupération (get), d'écriture (put), de suppression (delete) ou de listing (list) sur l'un des espaces de noms KV, ces services ont reçu à la place une erreur HTTP 401 Unauthorized (Échec de l'authentification).
Les clients utilisant les produits Cloudflare suivants peuvent avoir constaté des taux d'erreurs en hausse et/ou ne pas avoir été en mesure d'accéder à tout ou partie de leurs fonctionnalités pendant l'incident :
.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-7s56{background-color:#F4F5F7;text-align:left;vertical-align:top} .tg .tg-0lax{text-align:left;vertical-align:top}
| Product | Impact |
|---|---|
| Workers KV | Customers with applications leveraging KV saw those applications fail during the duration of this incident, including both the KV API within Workers, and the REST API. Workers applications not using KV were not impacted. |
| Pages | Applications hosted on Pages were unreachable for the duration of the incident and returned HTTP 500 errors to users. New Pages deployments also returned HTTP 500 errors to users for the duration. |
| Access | Users who were unauthenticated could not log in; any origin attempting to validate the JWT using the /certs endpoint would fail; any application with a device posture policy failed for all users. Existing logged-in sessions that did not use the /certs endpoint or posture checks were unaffected. Overall, a large percentage of existing sessions were still affected. |
| WARP / Zero Trust | Users were unable to register new devices or connect to resources subject to policies that enforce Device Posture checks or WARP Session timeouts. Devices already enrolled, resources not relying on device posture, or that had re-authorized outside of this window were unaffected. |
| Images | The Images API returned errors during the incident. Existing image delivery was not impacted. |
| Cache Purge (single file) | Single file purge was partially unavailable for the duration of the incident as some data centers could not access configuration data in KV. Data centers that had existing configuration data locally cached were unaffected. Other cache purge mechanisms, including purge by tag, were unaffected. |
| Workers | Uploading or editing Workers through the dashboard, wrangler or API returned errors during the incident. Deployed Workers were not impacted, unless they used KV. |
| AI Gateway | AI Gateway was not able to proxy requests for the duration of the incident. |
| Waiting Room | Waiting Room configuration is stored at the edge in Workers KV. Waiting Room configurations, and configuration changes, were unavailable and the service failed open. When access to KV was restored, some Waiting Room users would have experienced queuing as the service came back up. |
| Turnstile and Challenge Pages | Turnstile's JavaScript assets are stored in KV, and the entry point for Turnstile (api.js) was not able to be served. Clients accessing pages using Turnstile could not initialize the Turnstile widget and would have failed closed during the incident window. Challenge Pages (which products like Custom, Managed and Rate Limiting rules use) also use Turnstile infrastructure for presenting challenge pages to users under specific conditions, and would have blocked users who were presented with a challenge during that period. |
| Cloudflare Dashboard | Parts of the Cloudflare dashboard that rely on Turnstile and/or our internal feature flag tooling (which uses KV for configuration) returned errors to users for the duration. |
Produit
Impact
| Time | Description |
|---|---|
| 2023-10-30 18:58 UTC | The Workers KV team began a progressive deployment of a new KV build to production. |
| 2023-10-30 19:29 UTC | The internal progressive deployment API returns staging build GUID to a call to list production builds. |
| 2023-10-30 19:40 UTC | The progressive deployment API was used to continue rolling out the release. This routed a percentage of traffic to the wrong destination, triggering alerting and leading to the decision to roll back. |
| 2023-10-30 19:54 UTC | Rollback via progressive deployment API attempted, traffic starts to fail at scale. — IMPACT START — |
| 2023-10-30 20:15 UTC | Cloudflare engineers manually edit (via break glass mechanisms) deployment routes to revert to last known good build for the majority of traffic. |
| 2023-10-30 20:29 UTC | Workers KV error rates return to normal pre-incident levels, and impacted services recover within the following minute. |
| 2023-10-30 20:31 UTC | Impact resolved — IMPACT END — |
Workers KV
Les clients dont les applications reposent sur KV ont vu ces applications cesser de fonctionner correctement tout au long de l'incident, notamment l'API KV au sein de Workers et l'API REST.Les applications Workers qui n'utilisent pas KV n'ont pas été affectées.
Pages
Les applications hébergées sur Pages sont restées injoignables pendant toute la durée de l'incident et renvoyaient des erreurs HTTP 500 aux utilisateurs. Les nouveaux déploiements de Pages ont également renvoyé des erreurs HTTP 500 aux utilisateurs pendant l'incident.
Access
Les utilisateurs non authentifiés ne pouvaient pas se connecter. Les serveurs tentant de valider le JWT à l'aide du point de terminaison /certs ne pouvaient pas y parvenir. Les applications disposant d'une politique en matière de niveau de sécurité des appareils ont cessé de fonctionner pour tous les utilisateurs.Les sessions existantes déjà connectées qui n'utilisaient pas le point de terminaison /certs ou n'effectuaient pas de contrôle des politiques n'ont pas été touchées. Au total, un fort pourcentage des sessions existantes ont pourtant été affectées.
WARP / Zero Trust
Les utilisateurs ne pouvaient ni enregistrer de nouveaux appareils ni se connecter à des ressources soumises à des politiques appliquant des contrôles du niveau de sécurité des appareils ou des délais d'expiration des sessions WARP.Les ressources ne reposant pas sur une politique de niveau de sécurité des appareils ou qui avait été réautorisées en dehors de cette période n'ont pas été touchées, de même que les appareils déjà enregistrés.
Images
L'API Images a renvoyé des erreurs tout au long de l'incident. Les diffusions d'images existantes n'ont pas été affectées.
Purge du cache (un seul fichier)
La fonctionnalité de purge d'un seul fichier est restée partiellement indisponible pendant toute la durée de l'incident, car certains datacenters ne pouvaient pas accéder aux données de configuration conservées dans KV. Les datacenters qui disposaient des données de configuration en cache localement n'ont pas été touchés.Les autres mécanismes de purge, dont la purge par balise, sont restés non affectés.
Workers
Les opérations d'importation ou de modification de Workers via le tableau de bord, un wrangler ou une API ont renvoyé des erreurs pendant l'incident. Les Workers déployés n'ont pas été affectés, sauf s'ils utilisaient KV.
AI Gateway
La solution AI Gateway n'a pas pu mettre de requêtes en proxy pendant toute la durée de l'incident.
Waiting Room
La configuration de la solution Waiting Room est stockée à la périphérie du réseau, dans Workers KV. Les configurations de Waiting Room et les modifications de configuration n'étaient pas disponibles et le service est tombé en panne (en position ouverte).Lorsque l'accès à KV a été restauré, les utilisateurs de Waiting Room ont pu se retrouver en file d'attente lorsque le service a été rétabli.
Turnstile et pages de test
Les ressources JavaScript de Turnstile sont stockées dans KV et le point d'entrée de la solution (api.js) ne pouvait être desservi. Les clients qui accédaient à des pages utilisant Turnstile n'ont pas pu initialiser le widget Turnstile et sont restés en panne (en position fermée) pendant toute la durée de l'incident.Les pages de test (utilisées par divers produits, tels que les règles personnalisées, les règles gérées et les règles de contrôle du volume de requêtes) utilisent également l'infrastructure de Turnstile pour présenter des tests aux utilisateurs sous certaines conditions spécifiques. Elles bloquaient les utilisateurs qui se voyaient proposer un test pendant cette période.
Tableau de bord Cloudflare
Certaines parties du tableau de bord Cloudflare reposant sur Turnstile et/ou notre fonctionnalité interne d'identification (qui utilise KV pour la configuration) ont renvoyé des erreurs aux utilisateurs pendant toute la durée de l'incident.
Chronologie
Toutes les informations d'horodatage mentionnées sont en temps universel coordonné (UTC).
.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-ppch{background-color:#F4F5F7;color:#000000;font-weight:bold;text-align:left;vertical-align:top} .tg .tg-096r{color:#000000;text-align:left;vertical-align:top}
Temps
Description
2023-10-30 18:58 UTC
TL'équipe Workers KV entame le déploiement progressif d'une nouvelle version de KV vers la production.
2023-10-30 19:29 UTC
L'API interne de déploiement progressif renvoie un GUID de version en préproduction à un appel visant à dresser la liste des versions de production.
2023-10-30 19:40 UTC
L'API de déploiement progressif est utilisée pour poursuivre le déploiement de la version. Celle-ci achemine un certain pourcentage du trafic vers la mauvaise destination. La situation déclenche une alerte et conduit à la décision de revenir à une version antérieure (rollback).
2023-10-30 19:54 UTC
L'équipe tente un rollback via l'API de déploiement progressif. Le trafic commence à connaître des défaillances à grande échelle. — DÉBUT DES RÉPERCUSSIONS —
2023-10-30 20:15 UTC
Les techniciens Cloudflare modifient manuellement les itinéraires de déploiement (à l'aide de mécanismes d'urgence de type break glass) afin de revenir à la dernière version fonctionnelle connue pour la majorité du trafic.
2023-10-30 20:29 UTC
Le taux d'erreurs de Workers KV revient à son niveau normal pré-incident et les services affectés se rétablissent au cours de la minute suivante.
2023-10-30 20:31 UTC
Problème résolu — FIN DES RÉPERCUSSIONS —
Comme le montre la chronologie ci-dessus, on constate un retard entre le moment où nous nous sommes rendu compte que nous avions un problème, à 19 h 54 UTC, et le moment où nous avons effectivement pu procéder au rollback, à 20 h 15 UTC.
Ce retard est dû au fait que plusieurs outils au sein de l'environnement Cloudflare s'appuient sur Workers KV, dont Cloudflare Access. La solution Access utilise Workers KV dans le cadre de son processus de contrôle des requêtes. De ce fait, nous n'avons pas pu tirer parti de nos outils internes et avons dû passer par des mécanismes d'urgence pour contourner nos outils habituels. Comme décrit ci-dessous, nous n'avions pas passé suffisamment de temps à tester les mécanismes de rollback. Nous prévoyons de renforcer les tests à l'avenir.
Résolution
Les techniciens Cloudflare ont modifié manuellement (via un mécanisme d'urgence) l'itinéraire de production vers la version fonctionnelle précédente de Workers KV. Cette opération a immédiatement éliminé le chemin de requête défaillant et subséquemment résolu le problème affectant le déploiement de Workers KV.
Analyse
Workers KV est un référentiel clé-valeur à faible latence qui permet aux utilisateurs de stocker des données persistantes sur le réseau Cloudflare, aussi près de ces derniers que possible. Ce référentiel clé-valeur distribué est utilisé dans de nombreuses applications, dont certaines sont les propres produits de Cloudflare, comme les solutions Pages, Access et la plateforme Zero Trust.
L'équipe Workers KV a procédé au déploiement progressif d'une nouvelle version à l'aide d'un outil de déploiement spécialisé. Le mécanisme de déploiement contient un environnement de préproduction et un environnement de production. Il utilise un processus dans lequel ce dernier est mis à jour vers une nouvelle version de manière progressive, jusqu'à ce que tous les environnements de production exécutent la version de production la plus récente. L'outil de déploiement comportait un bug latent autour de la manière dont il renvoie les moutures et leurs versions respectives. Plutôt que de renvoyer les moutures depuis un environnement unique, l'outil renvoyait une liste de versions plus étendue que prévu. Les versions de production et de préproduction étaient ainsi renvoyées ensemble.
Lors de l'incident, le service avait été déployé et testé en préproduction. Or, en raison du bug de l'automatisation du déploiement, lors du passage en production, une référence incorrecte était effectuée à un script déployé sur le compte de préproduction plutôt qu'à la version de préproduction résidant sur le compte de production. En conséquence, le mécanisme de déploiement pointait l'environnement de production vers une version qui ne s'exécutait nulle part dans ce dernier. Le trafic se comportait alors dans les faits comme s'il avait été placé dans un « trou noir » (blackhole).
Lorsque cet événement s'est produit, le service Workers KV est devenu injoignable en production, car les appels effectués au produit étaient adressés à une version non autorisée pour l'accès à la production. Un code d'erreur HTTP 401 était donc renvoyé. Ce problème entraînait une défaillance des produits dépendants qui stockaient des paires clé-valeur dans KV, indépendamment du fait que ces paires soient mises en cache localement ou non.
Bien que la fonction d'alerte automatisée ait détecté immédiatement le problème, on constate un retard entre le moment où nous nous sommes rendu compte que nous avions un problème et le moment où nous avons effectivement pu procéder au rollback. Ce retard est dû au fait que plusieurs outils au sein de l'environnement Cloudflare s'appuient sur Workers KV, dont Cloudflare Access. La solution Access utilise Workers KV dans le cadre de son processus de vérification des JWT (JSON Web Tokens) de l'utilisateur.
Ces outils comprennent le tableau de bord utilisé pour annuler la modification et le mécanisme d'authentification servant à accéder à notre système d'intégration continue (CI, pour Continuous Integration). Comme Workers KV était en panne, ces services l'étaient également. Nous avions testé avec succès les rollbacks automatiques effectués via notre système CI par le passé, mais les problèmes d'authentification (Access dépend de KV) résultant de l'incident ont rendu impossible l'accès aux secrets nécessaires pour annuler le déploiement.
En définitive, le correctif que nous avons mis en œuvre était une modification manuelle du chemin de la version de production vers une version antérieure et fonctionnelle. Ce chemin était connu pour pointer vers la version de production précédente utilisée avant notre tentative de déploiement d'une nouvelle version.
Étapes suivantes
Comme un grand nombre d'équipes Cloudflare a développé sur Workers, nous avons fini « organiquement » par nous retrouver dans une situation dans laquelle Workers KV sous-tend un nombre impressionnant de produits et de services Cloudflare. L'incident à l'origine de l'article a contribué à renforcer la nécessité pour nous de revoir la manière dont nous pouvons réduire l'étendue des dépendances critiques. Cette révision inclut un plus haut degré de sophistication de nos outils de déploiement, leur simplicité d'utilisation pour nos équipes internes et des mesures de contrôle au niveau du produit concernant ces dépendances. Nous accordons la priorité à ces efforts afin de nous assurer que cet incident ne se reproduise jamais.
Ce dernier renforce également la nécessité pour nous d'améliorer nos outils et la sécurité de ces derniers autour de déploiements progressifs d'applications Workers, en interne et pour nos clients.
La liste ci-dessous présente certaines des actions de suivi essentielles à mettre en œuvre, sans s'y limiter, ce trimestre (aucun ordre spécifique) :
Intégrer les déploiements KV aux modèles de déploiement normalisés de Workers qui s'appuient sur des systèmes automatisés, pour une meilleure détection des impacts et une meilleure récupération de ces derniers.
S'assurer que le processus de rollback ait accès à un bon identifiant de déploiement connu et qu'il fonctionne lorsque Cloudflare Access est en panne.
Ajouter des mesures de contrôle préliminaires aux déploiements, afin de valider les paramètres d'entrée et de s'assurer que des versions non concordantes ne soient pas propagées aux environnements de production.
Renforcer l'outil de déploiement progressif afin qu'il fonctionne d'une manière pensée pour les architectures multitenant. La conception actuelle prend pour base le modèle single-tenant.
Ajouter une étape de validation supplémentaire aux scripts de déploiement progressif afin de vérifier que le déploiement corresponde à l'environnement applicatif (production, préproduction, etc.).
À nouveau, nous sommes vraiment navrés que cet incident se soit produit et prenons extrêmement au sérieux les répercussions de ce dernier sur nos clients.