Policy di egress

Una policy di egress definisce quali connessioni di rete in uscita un sistema può effettuare, per destinazione (un dominio o un intervallo IP), protocollo e porta, e che cosa succede a tutto il resto. Il filtraggio dell'egress è l'applicazione di tale policy da parte di un firewall, di un proxy o di una network policy. Un firewall di egress è il dispositivo o la funzionalità che la applica.

Default allow e default deny

Una policy default allow blocca un elenco di destinazioni note come malevole e lascia passare tutto il resto. Una policy default deny consente un elenco di destinazioni note come affidabili e blocca il resto. Kubernetes funziona allo stesso modo: un pod può raggiungere qualsiasi cosa finché una network policy non lo seleziona per l'egress, e da quel momento solo le connessioni che quella policy consente (network policy di Kubernetes).

Solo il default deny ferma il traffico verso una destinazione che nessuno aveva previsto, e il server di un attaccante è esattamente questo. Il costo è operativo: un'allowlist va costruita e mantenuta aggiornata.

Una egress policy default deny su Kubernetes

La documentazione di Kubernetes riporta questa policy, che seleziona tutti i pod di un namespace e non consente traffico in uscita (Kubernetes network policies):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
    - Egress

Blocca anche il DNS, quindi i workload che risolvono nomi hanno bisogno di una seconda policy che consenta il traffico in uscita verso il servizio DNS del cluster. Ogni destinazione consentita si aggiunge poi come un'altra policy, per pod, namespace o intervallo IP (ipBlock).

Policy basate su FQDN

Una NetworkPolicy standard seleziona pod, namespace e intervalli IP, non nomi di dominio. I registri di pacchetti stanno dietro content delivery network con indirizzi che cambiano, quindi le loro allowlist si scrivono per nome, come policy basate su FQDN aggiunte da alcuni plugin di rete. Le regole toFQDNs di Cilium selezionano un nome esatto con matchName o un pattern con matchPattern e ricavano gli indirizzi dalle risposte DNS che vede il suo proxy DNS (Cilium DNS-based policies). Calico Cloud e Calico Enterprise elencano domains nelle regole egress di tipo allow (Calico DNS policy).

Perché la CI ne ha bisogno

Un job di build custodisce chiavi di deploy, credenziali cloud e token, ed esegue gli script di installazione dei pacchetti che scarica. Una dipendenza compromessa può inviare quei secret ovunque il runner CI possa arrivare, ed è così che avviene l'esfiltrazione di token nella CI. La maggior parte dei runner consente per impostazione predefinita tutto il traffico in uscita.

Prenda uno script npm postinstall che invia le variabili d'ambiente del job a un host sconosciuto. Con una policy default deny che consente solo il registry npm e il Suo archivio di artefatti, la richiesta fallisce e i secret restano nel job.

Che cosa vede una build quando la policy la blocca

La connessione fallisce e la build segnala un normale errore di rete. A seconda di dove viene applicata la policy, si tratta di una connessione rifiutata o reimpostata, di un timeout, di una risoluzione DNS fallita o di un errore nell'handshake TLS, spesso dopo che il gestore di pacchetti ha riprovato. Allo sviluppatore sembra un registro instabile, ed è per questo che una buona egress policy registra ogni connessione bloccata con destinazione e motivo.

Che cosa valutare

• Destinazioni tipizzate. Registry di pacchetti indicati come sorgenti, non solo indirizzi IP, perché i registry stanno dietro content delivery network i cui indirizzi cambiano.
• Convalida prima dell'avvio del job, così una policy errata fallisce in modo visibile invece di essere applicata a metà.
• Fail-closed, così se l'applicazione non è disponibile il job non viene eseguito senza protezione.

Per l'introduzione in GitHub Actions, veda la policy di egress per GitHub Actions.

CRACI

CRACI applica una policy di egress sul runner, default deny o allow, con 24 preset integrati per sorgenti software e sorgenti personalizzate tipizzate per npm, PyPI, apt, apk, il proxy Go, Nix, Cargo, registry OCI e Git su HTTPS e SSH. La policy viene convalidata prima dell'avvio del job e opera in modalità fail-closed, e le violazioni generano avvisi. Lo stesso job registra quali pacchetti sono arrivati attraverso le connessioni consentite. Veda la sicurezza dei runner a confronto.

Quando la policy di CRACI blocca una connessione, il job vede un errore comune, come un 403 Forbidden, una connessione reimpostata, un EOF o un handshake TLS fallito, e la traccia di rete del job elenca la connessione tra le violazioni del proxy con un motivo, come no_match quando nessun preset, nessuna fonte e nessuna regola corrispondeva alla destinazione. La traccia si aggiorna in diretta nella vista del job mentre è in esecuzione ed è disponibile anche tramite API (documentazione CRACI: risolvere i problemi di rete).

Per il controllo dell'egress su carichi di lavoro Kubernetes, server o runner ospitati da GitHub che mantiene, usi una network policy, un firewall cloud o un agente sul runner: CRACI applica la propria policy solo sui propri runner, e una modalità audit prima del blocco è nella sua roadmap.