DNS, e-mail et webhooks

Ces intégrations transmettent les changements et événements d’Opfield à des systèmes externes : fournisseurs DNS, serveurs de messagerie et récepteurs de webhooks. Donnez à chacune des identifiants à privilèges minimaux et confirmez la réception du côté du destinataire : le fait qu’Opfield accepte un changement ne prouve pas que les résolveurs, les boîtes aux lettres ou les consommateurs de webhooks l’ont reçu.

Pour la configuration d’un connecteur DNS, suivez le guide Cloudflare dédié. Les e-mails et les webhooks de notification ou de déploiement sont des surfaces d’intégration distinctes, et non des comptes d’hébergement.

La configuration des e-mails prend en charge les processus d’authentification et l’envoi de notifications lorsqu’ils sont activés. Testez l’identité de l’expéditeur, TLS, la délivrabilité et les limites de débit avant de vous appuyer sur les codes à usage unique par e-mail.

Les webhooks peuvent déclencher des processus de déploiement ou d’automatisation pris en charge. Utilisez des secrets générés, vérifiez les signatures, rendez les récepteurs idempotents, et distinguez une opération acceptée d’un déploiement terminé. Ne renvoyez pas d’erreurs internes des démons ni d’identifiants dans les réponses aux webhooks.

Connecteurs DNS

Utilisez un jeton Cloudflare dédié, restreint au compte, aux zones et aux permissions DNS prévus. Vérifiez les zones visibles par ce jeton avant d’activer les enregistrements gérés ou les défis DNS-01. Opfield ne doit détenir que les enregistrements explicitement rattachés aux domaines gérés ; les enregistrements sans rapport restent un état externe.

Pour une migration, consignez les valeurs et le TTL actuels, confirmez l’adresse Ingress cible, appliquez le changement et vérifiez la résolution depuis des résolveurs publics indépendants. Ne supprimez pas l’ancien point de terminaison tant que le trafic client n’atteint pas le nouveau placement.

E-mail

Configurez l’identité de l’expéditeur, l’hôte SMTP, le port, le mode TLS et l’authentification selon le fournisseur, dans Settings > Advanced > SMTP configuration. Envoyez un message de test et vérifiez la boîte de réception réelle, le classement en spam, l’alignement SPF/DKIM/DMARC et les limites de débit du fournisseur.

Si les codes à usage unique par e-mail sont activés, maintenez un autre chemin de récupération pour les administrateurs. Une connexion SMTP réussie ne prouve pas que les utilisateurs peuvent recevoir les messages d’authentification.

Webhooks de notification

1. Créez un récepteur HTTPS avec une taille de requête et un délai d’expiration bornés.
2. Configurez l’authentification ou la signature HMAC.
3. Envoyez un événement de test et vérifiez la signature sur le corps brut de la requête.
4. Ne renvoyez une réponse de succès déterministe qu’une fois que le récepteur a accepté l’événement de manière durable.
5. Rendez les nouvelles tentatives idempotentes à l’aide de l’identifiant de l’événement ou de l’envoi.
6. Surveillez l’historique d’envoi, la latence, les nouvelles tentatives et les échecs définitifs.

Webhooks de déploiement

Considérez la réception d’un webhook comme une demande d’évaluation d’un événement de source, et non comme la preuve d’un déploiement. Vérifiez de façon indépendante la signature du fournisseur, la liste d’autorisation des dépôts, la politique de branches ou de tags, le commit résolu, l’admission du build et la tâche de déploiement finale.

Faites tourner les secrets des connecteurs et des webhooks en installant le remplaçant, en le vérifiant, puis en révoquant l’ancienne valeur. N’exposez pas aux appelants non fiables les réponses complètes des récepteurs, les identifiants des fournisseurs ni les erreurs internes des démons.

Modes de défaillance et reprise

Les pannes DNS proviennent couramment d’un mauvais compte ou d’une mauvaise zone, de permissions de jeton insuffisantes, de caches de résolveurs périmés, d’un mode proxy/CDN inattendu ou d’un enregistrement de défi qui ne peut pas être observé publiquement. Comparez l’enregistrement dans Opfield avec la réponse du serveur de noms faisant autorité et d’au moins un résolveur indépendant. Pendant une migration, rétablissez la valeur précédente consignée si le nouveau point de terminaison ne peut pas être vérifié avant l’échéance de retour arrière convenue.

L’envoi d’e-mails comporte plusieurs étapes indépendantes : Opfield a accepté le message, le fournisseur SMTP l’a accepté, le système destinataire l’a accepté, et l’utilisateur peut le retrouver. Vérifiez chaque étape avant de modifier la politique d’authentification. Si l’envoi des codes à usage unique est dégradé, gardez disponible le chemin d’administration alternatif testé et évitez de demander des codes à répétition, ce qui déclenche la limitation de débit du fournisseur.

Les échecs de webhooks nécessitent l’enregistrement d’envoi, le nombre de tentatives, la catégorie de réponse et l’identifiant de corrélation côté récepteur. Une réponse 2xx doit signifier que le récepteur a accepté l’événement de manière durable ; le traitement peut se poursuivre de façon asynchrone. Pour les échecs pouvant être retentés, faites dédupliquer le récepteur par identifiant d’envoi ou d’événement. Pour les échecs d’authentification définitifs, faites tourner le secret partagé ou la clé de signature et vérifiez les deux côtés avant de rejouer un nombre limité d’envois en échec.

Frontières de sécurité

Utilisez des points de terminaison HTTPS sans identifiants dans l’URL. Restreignez les destinations sortantes aux hôtes publics attendus ou à des CIDR privés explicitement approuvés. Les récepteurs doivent valider les horodatages ou les fenêtres de rejeu lorsque l’intégration les prend en charge, comparer les signatures en temps constant, limiter la taille des requêtes et éviter de renvoyer le corps des requêtes dans les réponses d’erreur.

Les jetons des fournisseurs DNS et de messagerie sont des identifiants d’administration, même lorsqu’Opfield les chiffre au repos. Gardez l’audit activé côté fournisseur, examinez régulièrement leur périmètre et ne révoquez l’ancien jeton qu’une fois que le remplaçant a réussi une vraie opération de test.

Pour l’authentification ou les notifications critiques pour l’activité, documentez un chemin alternatif de communication et de récupération des administrateurs. Le succès et la latence des fournisseurs externes échappent à la frontière de disponibilité d’Opfield ; ne faites donc pas d’un fournisseur non testé le seul moyen d’accéder à l’installation ou de l’exploiter.