"A Cloudflare dobja az Nginx-et"

Címkék

A Cloudflare eddig a népszerű Nginx-et használta a HTTP proxy stackjéhez, azonban elégetetlen volt annak teljesítményével. A saját fejlesztésű Pingora ezt kívánja orvosolni, a Cloudflare szerint 60-70 százalékkal kevesebb CPU-t és memóriát eszik, ráadásul a Rust nyelvnek köszönhetően biztonságosabb is.

Ez rossz hír az Nginx-nek, hiszen amennyiben Pingora - a Cloudflare ígéretének megfelelően - nyílt forráskódúvá válik a jövőben, az komolyan megingathatja a pozícióját. A Pingora projektről további információkat lehet olvasni a cég blogján.

Részletek itt.

Hozzászólások

Szerkesztve: 2022. 09. 17., szo – 09:33

elolvastam, hat ez nagyon specialis esetre van optimalizalva, https proxyzasra. azon nyertek sokat, hogy az nginx-el szemben ez jobban ki tudja hasznalni a keepalive-ot (connection reuse) a belso oldalon nagy terhelesnel es nagyon sok cpu eseten. azert ez ritkan tipikus use case. foleg hogy ennek akkor van csak jelentosege, ha nem csak 1-nehany szervert proxyzik hanem rengeteget.

ezek alapjan az nginx mint webszerver meg nem kell aggodjon, esetleg par helyen lecserelik mint proxyt.

Nyilvan minden szivarogtatas belulrol jon (by definition). De aligha ugy, hogy egy VPC halozati forgalmat tudnak sniffelni vhogy.

Tipikusan social engineeringgel/phising/etc. szereznek valid accountot es ugy fernek hozza erzekeny adatokhoz, ez ellen nem ved a halozati forgalom titkositasa. Sot, annak is van hatranya, ha minden Pod hozzafer a privat kulcsokhoz.

Storage titkositas azert az mas temakor, ott inkabb az a use-case, hogy mas cloud tenant ne ferjen hozza vagy barmifele HW maintenance (disk csere, storage csere, stb.) kozben ne keruljon ki adat.

> ez ellen nem ved a halozati forgalom titkositasa

Az ellen viszont igen, hogy ha ugyanazon a hoszton vagy fizikai halozati eszkozon sniffel. Ehhez eleg ha egy privilegizalt daemonsetet kepes futtatni vagy valamelyik priv mode-ban futo kontenert boritja meg, amibol szokott jopar futni.

> Sot, annak is van hatranya, ha minden Pod hozzafer a privat kulcsokhoz.

? Az mTLS eseten minden pod-nak sajat, rovid eletu kulcsa van.

> ha ugyanazon a hoszton

Leteznek erosen hardenelt hosztok, pl. bottlerocket. Nincs publikus IP, SSH sincs engedelyezve, shell sincs benne (ha jol tudom). Azt megneznem, ha vki egy ilyenre belep sniffelni.

> fizikai halozati eszkozon

Public cloudban? A cloud uzemelteto szemelyzettol probaljuk vedeni az adatainkat?

> eleg ha egy privilegizalt daemonsetet kepes futtatni

Ket eset lehetseges: vki megtorte a K8s API szervert (ennek mi valoszinusege?) vagy a sajat kolleganktol vedjuk a rendszert? Nyilvan jol kell beallitani/korlatozni a jogosultsagokat.

> valamelyik priv mode-ban futo kontenert boritja meg, amibol szokott jopar futni

Ezeknek aligha van publikus interface-e. Sajat kolleganktol vedjuk a rendszert?

> Az mTLS eseten minden pod-nak sajat, rovid eletu kulcsa van.

Ami egy Podon beluli sidecarban terminalodik (legalabbis istio eseten ugy tudom ugy van implementalva), a lenyegi process forgalma a localhoston keresztul van proxyzva a sidecar altal. Ergo ha vki megtori a hosztot, akkor a Podhoz tartozo network namespace lo interface-et is meg tudja sniffelni, ahol mar HTTP forgalomhoz fer hozza. Szerintem.

> Azt megneznem, ha vki egy ilyenre belep sniffelni.

Nem csak belepve lehet sniffelni.

Ha mar romma hardenelt hosztba invesztalsz, akkor a pont olyan regota megoldott problemat, mint a TLS a halozaton belul hagynad ki? Miert? Most tenyleg arrol vitatkozunk, h. a halozaton, ha a technika nem limitalja, az adat in-flight es at-rest legyen titkositva? Van olyan eset, amikor a zero-trust networking hatrany? (Most szamitsuk le az ezereves CPU-kat, amiben nincs AES-NI.)

> A cloud uzemelteto szemelyzettol probaljuk vedeni az adatainkat?

Is.

> vagy a sajat kolleganktol vedjuk a rendszert?

Is.

> Nyilvan jol kell beallitani/korlatozni a jogosultsagokat.

Nyilvan. Neha meg rosszul allitjuk be, mert ha nem lenne szarul megirt szoftver, akkor sokunk munkanelkuli lenne. Nyilvan.

> Ergo ha vki megtori a hosztot, akkor a Podhoz tartozo network namespace lo interface-et is meg tudja sniffelni

Vagy unix domain socketen, es akkor nem szivatjuk a CPU-t a TCP stackkel.

> Ha mar romma hardenelt hosztba invesztalsz, akkor a pont olyan regota megoldott problemat, mint a TLS a halozaton belul hagynad ki? Miert? Most tenyleg arrol vitatkozunk, h. a halozaton, ha a technika nem limitalja, az adat in-flight es at-rest legyen titkositva? Van olyan eset, amikor a zero-trust networking hatrany? (Most szamitsuk le az ezereves CPU-kat, amiben nincs AES-NI.)

Talan mert nagyon nem egyszeru a hasznalata/bevezetese/uzemeltetese?

Egyszer kozelebb kerultem az istiohoz. Ahogy kell, aszinkron volt a K8s release-hez kepest. Mire bevezetesre kerult, mar lehetett az upgrade-jen dolgozni. Allandoan varialtak a CRD-ket, kinlodas volt minden egyes upgrade. Es nem csak az istio maganak, hanem az osszes helm chartnak, amiben hasznalva voltak istios objektumok, azok is feszt megtortek. Debugolasa is rendkivul maceras volt, generalt envoy konfigokat kellett turni, logokban TLS hibak utan nyomozni.

Osszessegeben en ugy latom, hogy nagyon minimalis az a fenyegetettseg, amit kived, ellenben megsokszorozza az uzemeltetesi komplexitast, fenetudja hany outage-et okozva.

Egy storage at-rest encryption bekapcsolasa nehany sor a terraform konfigban, persze csinaljuk, mert teljesen transzparens. De ez a HTTPS mindenhova szemlelet szerintem eros. Persze, a TLS CPU igenye nem sok, viszont egy ilyen istios esetben meglehetosen sok SSL encrypt+decrypt tortenik, mire a kulso request megerkezik a Podon beluli processzhez, majd vissza a valasz. Ilyenkor vhol felsir Greta es Hajbazer :) Siman lehet, hogy emiatt nagyobbra kell skalazni egy terhelt Deploymentet. Raadasul plusz egy fo kell a DevOps csapatba, hogy legyeb eroforras az istio tutujgatashoz.

Biztos van istion kivul is elet, de vajon mi?

Minden microservice maga foglalkozhatna a TLS-sel, de akkor oda kell adni a private keyt vhogy: secretet mountolva, envvarkent, vmilyen vaultbol hozzaferve (de akkor a vaulthoz kell vmi secret)? A certet idonkent rotalni kell, Podokat ujrainditgatni, stb.

> istios esetben meglehetosen sok SSL encrypt+decrypt tortenik,

[kulvilag] -> Ingress -> pod. Ez csak +1 lepes. (A loadbalancer az lehet NLB). Az Istio-t nem kevernem ide, mert mi csak a TLS-rol beszeltunk, az Istio sokkal tobb mindent nyujt es valoban kihivas uzemeltetni.

En altalaban Calico CNI-t hasznok egyeb dolgok miatt is, es CNI-szinten tobb megoldast kinal IPSec-tol WireGuard-ig. https://projectcalico.docs.tigera.io/security/encrypt-cluster-pod-traff… .

> Minden microservice maga foglalkozhatna a TLS-sel, de akkor oda kell adni a private keyt vhogy: secretet mountolva

cert-manager ftw, a microservice pedig inotify() -n figyeli, h. valtozott-e. Vagy hozzaraksz egy nginx/haproxy/amitakarsz sidecart, ami unix domain socketen keresztul kommunikal a service-szel es akkor nem kell modositani a szolgaltatason. Ezt egy szolgaltatasra kidolgozod, es utana ez lehet a pattern. Ez a sidecar total ergya, nem kell tutujgatni.

Debuggolas alatt nem tudom mit ertesz, az eBPF cuccok ugyanugy mukodnek, WireSharkkal sniffelni viszont valoban nagyon korulmenyes :)

A lenyeg, h. ezeket egyszer talalod ki, utana nem igenyel kulonosebb figyelmet. Kb. mintha ALB-vel oldanad meg, annak is utana kellett nezned egyszer.

Meg ez a Calico CNI wireguard megoldasa tunik a "legegyszerubbnek". De ez is "csak" node-to-node encryptalast nyujt. Hosztra belepve sniffelheto a forgalom. Tehat csak felmegoldas a "jajj mi tortenik ha belepnek a hosztra" & "jajj sniffelnek a fizikai halozati eszkozokon" problemahalmazban.

cert-manager esetben ott vannak Secretben a TLS certek. A kollegak hozzafernek. Sok cert tobbe kerul(het).

> Kb. mintha ALB-vel oldanad meg, annak is utana kellett nezned egyszer.

Csak az letrehozhato/konfigolhato nehany sornyi annotationnel, a tobbit AWS intezi. Mig Calico-t, cert-manager-t pedig lehet update-elgetni a sok CRD-jukkel egyutt. A Calico projekt egyebkent szimpatikus, hasznaltam mar sokat.

Nyilvan nem megugorhatatlan feladat, csak a beszelgetes onnan indult, hogy "Felnott ember ilyet nem csinal". Kivancsi lennek vajon EKS/AKS/GKE-ben (de akar on-prem) hanyan encryptalnak internal forgalmat. Tippre 10% alatt lehet vhol. Ott latom jobban a letjogosultsagat, ha vki kulonallo datacenterek/regiok kozott ativelo K8s clustert csinal public halozaton keresztul. De azon is lehet segiteni VPC-k kozotti ipsec-kel. Meg hat miert is csinalna ilyet az ember.

> [kulvilag] -> Ingress -> pod. Ez csak +1 lepes.

Felteve, ha a Pod nem hiv meg tovabbi Podokat, akkor mar minden egyes hoppal no a TLS hasznalat.

De ne alljunk meg itt, a Fluentd is hasznaljon TLS-t a local ElasticSearchbe iraskor. OpenTracing/Jaeger esetben minden spant kuldjunk TLS encryptalva a local collectorba. Prometheus is TLS-en keresztul scrape-elje a /metric endpointot.

Hany TLS hasznalat ez mar?

Mert jon az audit.
Mert vannak uzemeltetesi standerdek amik eloirjak.

Hogy tenlyeg minek az mar mas kerdes.
Az audit nem nezi hogy load balancer egyaltalan verifikalja -e certet (nem szokta, mert elbukna).

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Sokszor az  uzemeltetesi auditnak nincs ertelme.

Peldaul volt olyan hely, ami pampogott azon, hogy nincs HSTS beallitva egy public facing service-hez, csak eppen azt felejtettek el, hogy ertelmetlen is, mert HTTP nem is volt soha a servicenel, csak HTTPS, azaz a HSTS header teljesen lenyegtelen.