Liste de blocage Nebula : diffusez-la, le phare ne le fera pas
Une entrée de liste de blocage ne s'applique que sur les hôtes qui l'ont chargée. Comparez la diffusion de la liste à la rotation de la CA, puis vérifiez un pair refusé et un pair qui fonctionne.
L'application d'une liste de blocage est une propriété de l'hôte qui effectue le contrôle, pas du certificat contrôlé. Une machine qui n'a jamais chargé l'entrée continue d'accepter l'identité, et rien dans la poignée de main ne vous prévient que deux pairs sont en désaccord. Le correctif bon marché et le correctif coûteux pour un justificatif exposé diffèrent par leur portée et par leur réversibilité, alors choisissez en connaissance de cause. Les sections suivantes couvrent ce que fait l'entrée, où elle doit être livrée, quand la rotation est la meilleure réponse et comment prouver que l'une ou l'autre a fonctionné.
Ce que fait réellement une entrée de liste de blocage
La configuration PKI énumère des empreintes qu'un hôte doit refuser même si le certificat est signé valablement et non expiré. L'application se fait localement, contre la liste que cet hôte a chargée au démarrage du service. Rien de l'entrée ne circule dans le certificat, aussi un pair ne peut pas apprendre la décision à partir du justificatif qu'on lui montre. C'est pourquoi un phare n'a aucun rôle ici : les phares aident les pairs à se trouver et à relayer le trafic là où un chemin direct échoue. Ils constituent une couche de découverte et de relais, pas un canal de distribution de configuration.
Mettre à jour une machine change les décisions de cette machine et laisse chaque autre pair exactement comme il était. Un pair qui fait confiance à l'autorité de signature et n'a jamais vu l'entrée n'a aucune raison de refuser quoi que ce soit. Tester la révocation en observant le phare ne prouve donc rien, car le composant que vous observez n'a jamais été chargé d'appliquer la liste.
Identifiez le certificat, pas l'appareil
Utilisez l'empreinte du justificatif que vous voulez refuser, car un nom d'hôte, une étiquette d'appareil ou une adresse actuelle identifient une machine aujourd'hui et autre chose le mois prochain. Aucune de ces chaînes n'apparaît dans la liste de blocage, et aucune ne survit à une réinstallation. Imprimez le certificat, lisez l'empreinte et vérifiez qu'elle appartient au justificatif mis au rebut et non à son remplacement. Lire les deux fichiers compte lorsqu'un remplacement est déjà émis, puisque l'ancien et le nouveau certificat peuvent partager un nom et différer dans tous les autres champs.
Notez quelle empreinte a été bloquée et quand, afin qu'un audit ultérieur distingue un changement achevé d'un changement prévu. Notez aussi ce que l'entrée ne fait pas : elle n'invalide pas l'autorité de signature et n'empêche pas l'acceptation d'un futur certificat de cette autorité. Bloquer le certificat d'un hôte et remplacer une autorité compromise sont deux opérations différentes aux conséquences différentes.
nebula-cert print -path /etc/nebula/host.crt
pki:
blocklist:
- "a1b2c3d4e5f6"Diffusez-la comme n'importe quelle autre configuration
Traitez la liste comme une configuration dotée d'un mécanisme de livraison, et non comme un fichier que quelqu'un modifie quand il y pense. Poussez la liste entière plutôt qu'un delta, afin qu'un hôte qui a manqué une mise à jour antérieure converge au lieu d'accumuler des lacunes. La documentation de Nebula PKI recommande exactement cela, et le conseil mérite d'être suivi à la lettre plutôt que reformulé en processus manuel.
Confirmez que le service en cours a rechargé le contenu, et pas seulement que le fichier sur le disque a changé. Suivez quelles machines ont appliqué le changement et gardez la liste en attente visible jusqu'à ce qu'elle soit vide. Un portable fermé une semaine est un pair qui n'a jamais appris la décision, et il peut se reconnecter depuis un réseau que personne n'attendait. Notez la méthode de livraison à côté de l'empreinte, car la prochaine révocation la réutilise et c'est sur la première que le processus se débogue.
Liste de blocage ou rotation de l'autorité
Une entrée de liste de blocage est étroite : une identité cesse de fonctionner et tout le reste continue. Faire tourner l'autorité de signature est large : chaque certificat qu'elle a émis devient non fiable, et chaque hôte a besoin d'un nouveau justificatif et d'une nouvelle ancre de confiance. La première est une révocation ciblée et la seconde une migration, elles demandent donc des approbations et des fenêtres de maintenance différentes. Le tableau place les deux côte à côte sur la portée, l'effort et la réversibilité.
| Question | Blocklist entry | Authority rotation |
|---|---|---|
| What stops working | One identity | Every certificate from that authority |
| Fleet work | Push one file and confirm a reload | New credentials and a new trust anchor everywhere |
| Reversible | Yes, remove the line | No, the old authority stays distrusted |
| Fits | A lost or stolen device | A leaked authority key |
Un portable perdu appelle la liste de blocage, car le rayon d'impact est une identité et le changement est réversible si vous avez bloqué la mauvaise empreinte. Une clé d'autorité divulguée appelle une rotation, car la liste de blocage ne peut pas aider pour des certificats qui n'ont pas encore été émis. Entre ces extrêmes, demandez si le justificatif exposé aurait pu signer autre chose, car une autorité représente plus qu'un hôte.
Écrivez la décision avant un incident, car choisir sous pression tend à produire par défaut l'option large. Quel que soit le chemin choisi, le travail restant est identique : prouver que l'application a eu lieu sur les hôtes qui comptent. Consigner l'empreinte et la date à ce moment-là est ce qui rend la preuve possible plus tard.
Vérifiez le refus et le reste
Connectez-vous depuis l'identité bloquée et confirmez l'échec, puis connectez-vous depuis un pair autorisé et confirmez qu'il atteint toujours ce dont il a besoin. Un changement qui casse tout le monde n'est pas une révocation réussie. Faites les deux depuis des sessions neuves, car un état mis en cache peut masquer le résultat.
Vérifiez si une session établie se termine après le changement, et notez le comportement pour votre version et votre configuration au lieu de supposer que modifier un fichier met fin à quoi que ce soit. L'option disconnect_invalid couvre les clients dont les certificats sont expirés ou invalides, alors confirmez comment elle s'applique à votre cas avant de vous y fier. Si la terminaison immédiate est une exigence, testez-la spécifiquement et notez ce que vous avez observé. Répétez ensuite le test après un redémarrage, car un hôte qui n'applique la liste que jusqu'au prochain démarrage a un problème de livraison que le premier test a masqué. Un phare sain vous dit que la découverte fonctionne, pas qu'un pair a appliqué une politique.