Llista de bloqueig de Nebula: distribueix-la, el far no ho farà

L'aplicació de la llista de bloqueig és una propietat de l'amfitrió que fa la comprovació, no del certificat que es comprova. Una màquina que mai no ha carregat l'entrada continua acceptant la identitat, i res a l'apretada de mans no us avisa que dos parells no estan d'acord. La solució barata i la solució cara per a una credencial exposada difereixen en abast i en reversibilitat, així que trieu deliberadament. Les seccions següents tracten què fa l'entrada, on s'ha de lliurar, quan la rotació és la millor resposta i com demostrar que qualsevol de les dues ha funcionat.

Què fa realment una entrada de la llista de bloqueig

La configuració de PKI llista empremtes que un amfitrió ha de rebutjar encara que el certificat estigui vàlidament signat i no hagi caducat. L'aplicació passa localment, contra la llista que aquell amfitrió va carregar quan es va iniciar el servei. Res de l'entrada no viatja dins del certificat, així que un parell no pot aprendre la decisió de la credencial que se li mostra. Per això un far no hi té cap paper: els fars ajuden els parells a trobar-se i a retransmetre trànsit on falla un camí directe. Són una capa de descobriment i retransmissió, no un canal de distribució de configuració.

Actualitzar una màquina canvia les decisions d'aquella màquina i deixa cada altre parell exactament com estava. Un parell que confia en l'autoritat de signatura i mai no ha vist l'entrada no té cap motiu per rebutjar res. Per tant, provar la revocació mirant el far no demostra res, perquè el component que mireu mai no ha estat requerit per aplicar la llista.

Identifiqueu el certificat, no el dispositiu

Feu servir l'empremta de la credencial que voleu rebutjar, perquè un nom d'amfitrió, una etiqueta de dispositiu o una adreça actual identifiquen una màquina avui i una altra cosa el mes que ve. Cap d'aquestes cadenes no apareix a la llista de bloqueig, i cap no sobreviu a una reinstal·lació. Imprimiu el certificat, llegiu l'empremta i comproveu que pertany a la credencial que es retira i no al seu reemplaçament. Llegir tots dos fitxers importa quan ja s'ha emès un reemplaçament, ja que el certificat vell i el nou poden compartir nom i diferir en tots els altres camps.

Registreu quina empremta s'ha bloquejat i quan, perquè una auditoria posterior separi un canvi complet d'un canvi previst. Fixeu-vos també en què no fa l'entrada: no invalida l'autoritat de signatura i no impedeix que s'accepti un certificat futur d'aquella autoritat. Bloquejar el certificat d'un amfitrió i reemplaçar una autoritat compromesa són operacions diferents amb conseqüències diferents.

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

Distribueix-la com qualsevol altra configuració

Tracteu la llista com una configuració amb un mecanisme de lliurament i no com un fitxer que algú edita quan se'n recorda. Envieu la llista sencera en lloc d'un delta, perquè un amfitrió que es va perdre una actualització anterior convergeixi en lloc d'acumular buits. La documentació de Nebula PKI recomana exactament això, i val la pena seguir el consell literalment en lloc de convertir-lo en un procés manual.

Confirmeu que el servei en execució ha recarregat el contingut, no només que el fitxer del disc ha canviat. Seguiu quines màquines han aplicat el canvi i manteniu visible la llista pendent fins que sigui buida. Un ordinador portàtil tancat una setmana és un parell que mai no ha après la decisió, i pot reconnectar-se des d'una xarxa que ningú no esperava. Registreu el mètode de lliurament al costat de l'empremta, perquè la revocació següent el reutilitza i és a la primera on es depura el procés.

Llista de bloqueig o rotació de l'autoritat

Una entrada de la llista de bloqueig és estreta: una identitat deixa de funcionar i tota la resta continua. Rotar l'autoritat de signatura és ampli: cada certificat que ha emès esdevé no fiable, i cada amfitrió necessita una credencial nova i un ancoratge de confiança nou. La primera és una revocació dirigida i la segona és una migració, així que necessiten aprovacions diferents i finestres de manteniment diferents. La taula posa les dues costat a costat en abast, esforç i reversibilitat.

Un portàtil perdut demana la llista de bloqueig, perquè el radi d'impacte és una identitat i el canvi és reversible si heu bloquejat l'empremta equivocada. Una clau d'autoritat filtrada demana rotació, perquè la llista de bloqueig no pot ajudar amb certificats que encara no s'han emès. Entre aquests extrems, pregunteu si la credencial exposada podia haver signat alguna altra cosa, ja que una autoritat és més d'un amfitrió.

Escriviu la decisió abans d'un incident, perquè triar sota pressió tendeix a produir l'opció àmplia per defecte. Prengueu el camí que prengueu, la tasca pendent és idèntica: demostrar que l'aplicació ha passat als amfitrions que importen. Registrar l'empremta i la data en aquell moment és el que fa possible la prova més endavant.

Verifiqueu el rebuig i la resta

Connecteu des de la identitat bloquejada i confirmeu la fallada, després connecteu des d'un parell autoritzat i confirmeu que encara arriba al que necessita. Un canvi que trenca tothom no és una revocació reeixida. Feu les dues coses des de sessions noves, perquè l'estat en memòria cau pot amagar el resultat.

Comproveu si una sessió establerta acaba després del canvi, i anoteu el comportament per a la vostra versió i configuració en lloc de suposar que editar un fitxer atura alguna cosa. L'opció disconnect_invalid cobreix els clients els certificats dels quals han caducat o són invàlids, així que confirmeu com s'aplica al vostre cas abans de confiar-hi. Si l'aturada immediata és un requisit, proveu-ho específicament i anoteu què heu observat. Després repetiu la prova després d'un reinici, perquè un amfitrió que només aplica la llista fins al proper reinici té un problema de lliurament que la primera prova va amagar. Un far saludable us diu que el descobriment funciona, no que cap parell hagi aplicat una política.