Un servidor de laboratori, tres rols de confiança, un sol domini de fallada

Tot funciona fins que l’executor de compilació necessita el mateix sòcol d’amfitrió que utilitza el convidat VPN, i aleshores ningú no pot explicar per què una tasca pot llegir les claus de la passarel·la. Tot es va instal·lar en una sola màquina perquè hi cabia, i a cada convidat se li va donar accés ampli perquè era la manera més ràpida de fer-ho funcionar. El resultat és un amfitrió la frontera de confiança del qual és el cable d’alimentació. Separar els rols costa menys feina del que sembla, i comença per donar-los nom.

Tres rols que ara comparteixen tot

Una entrada VPN, un conjunt de serveis privats i un executor de compilació volen coses diferents. El primer necessita un port públic i una xarxa estreta pel costat privat. El segon necessita emmagatzematge persistent i secrets d’aplicació. El tercer executa codi que ha escrit una altra persona.

Donar a tots tres el mateix accés és el que fa confús el símptoma, perquè aleshores qualsevol d’ells pot afectar els altres. Una tasca de compilació que pot arribar al sòcol de l’hipervisor és una tasca que pot aturar la VPN. Un convidat de serveis amb una ruta a la xarxa de gestió pot canviar la configuració del commutador. Els privilegis són el problema, i la llista de processos només és on es veu. Anomenar primer els rols dona a cada privilegi un lloc on viure.

L’esbós de sota és un punt de partida per a aquesta separació, no una promesa d’alta disponibilitat. Tracta’l com una hipòtesi a verificar, no com el disseny acabat.

Separa tres rols, no tres processos

Tres convidats en un amfitrió donen tres conjunts de privilegis i tres posicions de xarxa. No donen tres dominis de fallada, i el disseny ho hauria de dir en veu alta.

La separació només ajuda si un compromís en un convidat no atorga automàticament els altres, i això és un paràmetre de l’hipervisor, no una convenció de noms. Anomenar una VM passarel·la no impedeix que un altre convidat arribi a l’amfitrió. Llegeix la configuració del commutador virtual en lloc del nom d’amfitrió i després confirma que cada convidat és on creus.

host
├─ vpn-gw      10.60.10.2/24   public 51820/udp only
├─ services    10.60.0.10/24   no route to the management network
└─ ci-runner   10.60.20.2/24   outbound only, no host socket

Escriu la topologia i després verifica-la amb les eines que la posseeixen. Un convidat que apareix al pont equivocat és una troballa, no un detall. Corregeix la xarxa abans de canviar qualsevol configuració de servei.

Deixa que el convidat VPN obri només les portes que posseeix

Publica el port del túnel al router i res més. Els ports d’administració de convidats pertanyen a un camí de gestió, no a internet, i la interfície pròpia de l’hipervisor també hi pertany.

La xarxa del costat privat hauria d’arribar als serveis que necessiten els usuaris remots i aturar-se allà. L’autenticació de l’aplicació continua activada, perquè un túnel és transport i no un inici de sessió. Mantén la taula d’encaminament del convidat VPN prou petita per descriure-la en una frase. Si no la pots descriure amb aquesta senzillesa, la frontera ja s’ha difuminat.

virsh net-list --all
virsh net-dumpxml lab-private
sudo nft list ruleset | grep -n -E '51820|10.60'

Qualsevol cosa que escolti a l’amfitrió i no calgui per a la gestió no hauria d’escoltar gens. Això inclou l’API de l’hipervisor, que és fàcil de deixar exposada en una interfície pública.

Les tasques de compilació necessiten un altre tipus de frontera

Una tasca CI executa ordres controlades pel repositori, així que la seva confiança depèn de qui pot pujar codi. Un executor d’intèrpret executa aquestes ordres com l’usuari de l’executor a l’amfitrió, i aquesta és la frontera més àmplia disponible.

Els executors de contenidors són més estrets, i un contenidor privilegiat no és dels estrets. Mantén l’executor en el seu propi convidat amb el seu propi abast de xarxa, i dona-li només l’accés a artefactes i desplegament que necessiten les tasques. Els treballadors d’un sol ús redueixen l’estat retingut; no redueixen l’abastabilitat ni l’exposició de secrets. Totes dues coses encara necessiten límits explícits.

El convidat de serveis posseeix les dades, així que el seu pla de còpia de seguretat és el que ha de funcionar. Mantén els repositoris, les pujades i la base de dades en el mateix calendari. Prova una restauració en lloc de llegir l’estat de la tasca.

Planifica la fallada que comparteixen tots tres

Un amfitrió és un domini de fallada. Un reinici elimina el túnel i tots els serveis privats en el mateix moment, i és exactament quan una via d’entrada importa més.

Conserva un accés per consola que no depengui del convidat VPN, sigui una consola física, una interfície de gestió fora de banda o una consola del proveïdor. Una instantània desada al mateix disc no és una còpia independent, i una còpia de seguretat que s’executa dins del convidat que protegeix tampoc. Després prova l’arrencada en fred com una seqüència i no com una llista: amfitrió, xarxes virtuals, camí del túnel i una aplicació anomenada sota un compte ordinari.

virsh list --all
systemctl is-active libvirtd
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://10.60.0.10/
ss -ltnp | grep -E ':51820|:443'

L’ordre d’inici dels processos no demostra res sobre rutes i DNS, així que prova el camí en lloc dels estats de les unitats. El camí és el que un usuari remot necessita de veritat.