Egress-käytäntö

Egress-käytäntö (egress policy) eli lähtevän liikenteen käytäntö määrittää, mitä lähteviä verkkoyhteyksiä järjestelmä saa muodostaa kohteen (verkkotunnus tai IP-osoitealue), protokollan ja portin mukaan, ja mitä kaikelle muulle tapahtuu. Lähtevän liikenteen suodatus (egress filtering) on tällaisen käytännön toimeenpanoa palomuurilla, välityspalvelimella tai verkkokäytännöllä. Egress-palomuuri on laite tai toiminto, joka toimeenpanee sen.

Oletuksena salliva ja oletuksena estävä

Oletuksena salliva käytäntö estää listan tunnetusti haitallisia kohteita ja päästää kaiken muun läpi. Oletuksena estävä käytäntö sallii listan tunnetusti hyviä kohteita ja estää loput. Kubernetes toimii samoin: pod voi tavoittaa mitä tahansa, kunnes verkkokäytäntö valitsee sen lähtevän liikenteen osalta, ja siitä eteenpäin vain ne yhteydet, jotka käytäntö sallii (Kubernetes network policies).

Vain oletuksena estävä käytäntö pysäyttää liikenteen kohteeseen, jota kukaan ei osannut ennakoida, ja hyökkääjän palvelin on juuri sellainen. Hinta on operatiivinen: sallittujen lista on rakennettava ja pidettävä ajan tasalla.

Oletuksena estävä egress-käytäntö Kubernetesissa

Kubernetesin dokumentaatio antaa tämän käytännön, joka valitsee nimiavaruuden jokaisen podin eikä salli lainkaan lähtevää liikennettä (Kubernetes network policies):

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

Se estää myös DNS:n, joten nimiä selvittävät kuormat tarvitsevat toisen käytännön, joka sallii lähtevän liikenteen klusterin DNS-palveluun. Jokainen sallittu kohde lisätään sitten omana käytäntönään podin, nimiavaruuden tai IP-osoitealueen (ipBlock) mukaan.

FQDN-pohjaiset käytännöt

Tavallinen NetworkPolicy täsmää podeihin, nimiavaruuksiin ja IP-osoitealueisiin, ei verkkotunnuksiin. Pakettirekisterit ovat sisällönjakeluverkkojen takana, ja niiden osoitteet vaihtuvat, joten niiden sallittujen listat kirjoitetaan nimillä FQDN-pohjaisina käytäntöinä, joita osa verkkolisäosista tarjoaa. Ciliumin toFQDNs-säännöt täsmäävät tarkkaan nimeen matchName-kentällä tai jokerimerkkiin matchPattern-kentällä ja oppivat osoitteet DNS-vastauksista, jotka sen DNS-välityspalvelin näkee (Cilium DNS-based policies). Calico Cloud ja Calico Enterprise luettelevat domains-kentän lähtevän liikenteen sallintasäännöissä (Calico DNS policy).

Miksi CI tarvitsee sen

Build-jobilla on hallussaan käyttöönottoavaimia, pilvitunnuksia ja tokeneita, ja se ajaa lataamiensa pakettien asennusskriptejä. Vaarantunut riippuvuus voi lähettää nämä salaisuudet minne tahansa, minne CI-runneri pääsee, ja juuri näin tokenien vuotaminen tapahtuu CI:ssä. Useimmat runnerit sallivat oletuksena kaiken lähtevän liikenteen.

Otetaan esimerkiksi npm:n postinstall-skripti, joka lähettää jobin ympäristömuuttujat tuntemattomalle palvelimelle. Oletuksena estävällä käytännöllä, joka sallii vain npm-rekisterin ja artefaktivarastosi, pyyntö epäonnistuu ja salaisuudet pysyvät jobissa.

Mitä buildi näkee, kun käytäntö estää sen

Yhteys epäonnistuu, ja buildi raportoi tavallisen verkkovirheen. Sen mukaan, missä käytäntö toimeenpannaan, se on hylätty tai nollattu yhteys, aikakatkaisu, epäonnistunut DNS-haku tai TLS-kättelyn virhe, usein sen jälkeen, kun paketinhallinta on yrittänyt uudelleen. Kehittäjälle se näyttää epäluotettavalta rekisteriltä, ja siksi hyvä egress-käytäntö kirjaa jokaisen estetyn yhteyden kohteineen ja eston syineen.

Mihin kiinnittää huomiota

• Tyypitetyt kohteet. Pakettirekisterit nimetään lähteiksi, ei pelkkinä IP-osoitteina, koska rekisterit ovat sisällönjakeluverkkojen takana ja niiden osoitteet vaihtuvat.
• Validointi ennen jobin käynnistymistä, jotta rikkinäinen käytäntö epäonnistuu näkyvästi eikä jää puoliksi voimaan.
• Fail closed, eli jos toimeenpano ei ole käytettävissä, jobia ei ajeta ilman suojausta.

Käyttöönotosta GitHub Actionsissa: GitHub Actionsin egress-käytäntö.

CRACI

CRACI toimeenpanee egress-käytännön runnerilla, oletuksena estävänä tai sallivana, ja käytössä on 24 valmista ohjelmistolähteiden esiasetusta sekä tyypitetyt omat lähteet npm:lle, PyPI:lle, aptille, apk:lle, Go-proxylle, Nixille, Cargolle, OCI-rekistereille ja Gitille HTTPS:n ja SSH:n yli. Käytäntö validoidaan ennen jobin käynnistymistä, virhetilanteessa liikenne estetään (fail closed), ja rikkomukset nostavat hälytyksiä. Sama jobi tallentaa, mitkä paketit tulivat sallittujen yhteyksien kautta. Katso runnereiden tietoturva vertailussa.

Kun CRACI:n käytäntö estää yhteyden, jobi näkee tavallisen virheen, kuten 403 Forbidden, nollatun yhteyden, EOF:n tai TLS-kättelyn epäonnistumisen, ja jobin verkkojälki listaa yhteyden kohdassa proxy violations syineen, esimerkiksi no_match, kun mikään esiasetus, lähde tai sääntö ei täsmännyt kohteeseen. Jälki päivittyy jobinäkymään jobin ajon aikana, ja se on saatavilla myös API:n kautta (CRACI docs: debug network problems).

Kubernetes-kuormien, palvelimien tai itse pitämiesi GitHubin ylläpitämien runnereiden lähtevän liikenteen hallintaan käytä verkkokäytäntöä, pilvipalomuuria tai runneriagenttia: CRACI toimeenpanee käytäntönsä vain omilla runnereillaan, ja estoa edeltävä audit-tila on sen tiekartalla.