Esposizione del registro dei container

Cos’è Esposizione del registro dei container?

Un registro che consente il pull anonimo consegna la tua fonte, la tua configurazione e il tuo artefatto distribuito a chiunque indovini il nome del repository. Il push anonimo consente a un utente malintenzionato di sovrascrivere il tag che stai per spedire e la pipeline non si accorge di nulla. Potrai estrarre un'immagine di produzione, ricostruirla con un impianto, rimetterla sotto lo stesso tag di rilascio e eseguire l'impianto all'interno del servizio in esecuzione. Quindi richiederai l'autenticazione, il push dell'ambito, contrassegnare i tag di rilascio come immutabili e verificare l'immagine distribuita tramite digest anziché tramite tag.

Cosa imparerai in Esposizione del registro dei container

• Riconosci che il pull anonimo su un repository privato consegna a un utente malintenzionato la tua fonte, la tua configurazione e i tuoi livelli di build
• Rintraccia una distribuzione avvelenata a un utente malintenzionato che ha ricostruito l'immagine di produzione e l'ha reimpostata sotto lo stesso tag di rilascio
• Configurare una policy del registro che richieda l'autenticazione per il pull e l'ambito del push ai repository effettivamente creati da una pipeline
• Contrassegna i tag di rilascio come immutabili in modo che un tag esistente non possa essere ripubblicato su contenuti che nessuno ha testato o rivisto
• Verifica un'immagine distribuita confrontando il suo digest con il digest registrato dalla pipeline, poiché un tag si sposta ma un digest non può

Esposizione del registro dei container — Fasi della formazione

1. Cerca un repository pubblico

   Bob non prende di mira Quenmoor per nome. Sonda i registri self-hosted alla ricerca di quelli che rispondono senza un login, poi enumera i loro repository per trovarne uno lasciato leggibile. Il registro di Quenmoor risponde, e un repository spicca.

2. Un repository privato lasciato aperto

   Bob sonda i registri self-hosted alla ricerca di repository a cui non dovrebbe poter accedere. Il registro di Quenmoor gli ha risposto senza chiedergli chi fosse, e un repository spicca: un servizio interno di dispacciamento.

3. Pubblico, e scrivibile

   Questo è un servizio interno, ma la sua policy di accesso è completamente aperta. Bob legge le due impostazioni che gli interessano.

4. Scaricalo in modo anonimo

   Nessuna credenziale, nessuna appartenenza, nessuna richiesta di accesso. Bob punta Docker verso il registro e scarica direttamente l'immagine di produzione.

5. Leggi la loro configurazione di produzione

   L'immagine non è solo codice. Porta con sé la configurazione con cui viene eseguita, incorporata in un livello. Bob avvia un container da essa e legge quel file direttamente.

6. Ricostruiscila con una backdoor

   Leggere l'immagine era un furto; sovrascriverla è controllo. Poiché ha scaricato la loro vera immagine di produzione, Bob la ricostruisce direttamente a partire da essa e aggiunge un singolo livello. Questo è il Dockerfile.

7. Il livello che ha aggiunto

   Tutto il resto è la loro immagine, invariata. Un solo RUN la trasforma in un punto d'appoggio che viene distribuito a ogni deploy.

8. Taggala come la loro release

   Bob costruisce l'immagine avvelenata e la tagga con il nome esatto da cui Quenmoor distribuisce, così il registro la tratterà come la release di produzione.

9. Pubblica un tag avvelenato

   Leggere l'immagine è un furto. Sovrascriverla è controllo. Bob ricostruisce l'immagine con una backdoor nel suo entrypoint e la ripubblica sull'esatto tag da cui Quenmoor distribuisce. Il registro la accetta senza chiedergli chi sia.

10. Cosa gli ha fruttato il push

    Il deploy successivo ha portato il tag di Bob in produzione, e il livello che ha aggiunto ha telefonato a casa dall'interno del servizio in esecuzione. Non deve più raggiungere Quenmoor dall'esterno: il suo codice è il servizio.