Lista de bloqueo de Nebula: distribúea, o faro non

A aplicación da lista de bloqueo é unha propiedade do host que fai a comprobación, non do certificado que se comproba. Unha máquina que nunca cargou a entrada segue aceptando a identidade, e nada no handshake avisa de que dous pares non están de acordo. A solución barata e a solución cara para unha credencial exposta difiren en alcance e en reversibilidade, así que escolle con deliberación. As seccións seguintes cobre que fai a entrada, onde se ten que entregar, cando a rotación é a mellor resposta e como demostrar que calquera das dúas funcionou.

Que fai realmente unha entrada da lista de bloqueo

A configuración da PKI lista as impresións dixitais que un host debe rexeitar aínda que o certificado estea asinado validamente e non caducase. A aplicación ocorre localmente, contra a lista que ese host cargou cando arrancou o servizo. Nada da entrada viaxa dentro do certificado, polo que un par non pode aprender a decisión a partir da credencial que se lle mostra. Por iso un faro non xoga ningún papel aquí: os faros axudan aos pares a atoparse e a retransmitir tráfico onde falla unha ruta directa. Son unha capa de descuberta e retransmisión, non un canal de distribución de configuración.

Actualizar unha máquina cambia as decisións desa máquina e deixa todos os demais pares exactamente como estaban. Un par que confía na autoridade de sinatura e nunca viu a entrada non ten motivo para rexeitar nada. Probar a revogación observando o faro, polo tanto, non demostra nada, porque ao compoñente que observas nunca se lle pediu aplicar a lista.

Identifica o certificado, non o dispositivo

Usa a impresión dixital da credencial que pretendes rexeitar, porque un nome de host, unha etiqueta de dispositivo ou un enderezo actual identifican unha máquina hoxe e outra cousa o mes que vén. Ningunha desas cadeas aparece na lista de bloqueo, e ningunha sobrevive a unha reinstalación. Imprime o certificado, le a impresión dixital e comproba que pertence á credencial que se retira e non á súa substitución. Ler ambos ficheiros importa cando xa se emitiu unha substitución, xa que os certificados vello e novo poden compartir un nome e diferir en todos os demais campos.

Rexistra que impresión dixital se bloqueou e cando, para que unha auditoría posterior separe un cambio completado dun pretendido. Anota tamén o que a entrada non fai: non invalida a autoridade de sinatura e non impide que se acepte un certificado futuro desa autoridade. Bloquear un certificado de host e substituír unha autoridade comprometida son operacións distintas con consecuencias distintas.

nebula-cert print -path /etc/nebula/host.crt
pki:
  blocklist:
    - "a1b2c3d4e5f6"

Distribúea como calquera outra configuración

Trata a lista como configuración cun mecanismo de entrega e non como un ficheiro que alguén edita cando se lembra. Envía a lista completa en vez dun delta, para que un host que perdeu unha actualización anterior converxa en lugar de acumular ocos. A documentación da PKI de Nebula recomenda exactamente iso, e vale a pena seguir o consello literalmente en vez de parafrasearlo nun proceso manual.

Confirma que o servizo en execución recargou o contido, non só que cambiou o ficheiro no disco. Fai seguimento das máquinas que aplicaron o cambio e mantén visible a lista pendente ata que quede baleira. Un portátil pechado durante unha semana é un par que nunca aprendeu a decisión, e pode reconectarse desde unha rede que ninguén esperaba. Rexistra o método de entrega xunto á impresión dixital, porque a próxima revogación reutilízao e é na primeira onde se depura o proceso.

Lista de bloqueo ou rotación da autoridade

Unha entrada da lista de bloqueo é estreita: unha identidade deixa de funcionar e todo o demais continúa. Rotar a autoridade de sinatura é amplo: cada certificado que emitiu pasa a non ser de confianza, e cada host necesita unha credencial nova e unha nova áncora de confianza. A primeira é unha revogación dirixida e a segunda é unha migración, polo que necesitan aprobacións distintas e ventás de mantemento distintas. A táboa pon as dúas lado a lado en alcance, esforzo e reversibilidade.

Un portátil perdido pide a lista de bloqueo, porque o raio de dano é unha identidade e o cambio é reversible se bloqueaches a impresión dixital equivocada. Unha clave de autoridade filtrada pide rotación, porque a lista de bloqueo non pode axudar con certificados que aínda non se emitiron. Entre eses extremos, pregunta se a credencial exposta podería asinar algo máis, xa que unha autoridade é máis que un host.

Escribe a decisión antes dun incidente, porque elixir baixo presión tende a producir a opción ampla por defecto. Sexa cal sexa o camiño que tomes, o elemento de traballo restante é idéntico: demostrar que a aplicación ocorreu nos hosts que importan. Rexistrar a impresión dixital e a data nese momento é o que fai posible a proba máis tarde.

Verifica o rexeitamento e o resto

Conéctate desde a identidade bloqueada e confirma o fallo, despois conéctate desde un par autorizado e confirma que aínda alcanza o que necesita. Un cambio que rompe con todos non é unha revogación exitosa. Fai ambas as cousas desde sesións novas, porque o estado en caché pode ocultar o resultado.

Comproba se unha sesión establecida remata despois do cambio, e anota o comportamento para a túa versión e configuración en vez de asumir que editar un ficheiro remata algo. A opción disconnect_invalid cobre os clientes cuxos certificados están caducados ou non son válidos, así que confirma como se aplica ao teu caso antes de confiar nela. Se o remate inmediato é un requisito, proba iso específicamente e rexistra o que observaches. Despois repite a proba tras un reinicio, porque un host que aplica a lista só ata o seguinte reinicio ten un problema de entrega que a primeira proba ocultou. Un faro san diche que a descuberta funciona, non que algún par aplicase unha política.