Security

Ma reggel egy Slack üzenetre ébredtem a security leadtől: “az axiost megtörték npm-en.” Azt hittem vicc. Az axiosnak heti 60 millió letöltése van. Az ember feltételezi, hogy biztonságos, mert mindenki használja. Nem volt vicc. Mi történt pontosan Két kártékony verzió jelent meg npm-en éjszaka: [email protected] és [email protected]. A támadó megszerezte az egyik fő maintainer npm hitelesítő adatait, átírta a fiók emailjét egy ProtonMail címre, és kézzel publisholt npm CLI-vel. Nem volt pull request. Nem volt CI futás. Nem volt code review. Csak egy npm publish egy lopott fiókból. ...

A múlt héten egy teljes szombatot azzal töltöttem, hogy végigauditáltam minden GitHub Actions workflowt az összes repónkban. Nem azért, mert akartam, hanem azért, mert a Trivy elleni supply chain támadás ráébresztett, milyen vékony jégen táncolok. Ha lemaradtál volna: valaki sikeresen becsempészett egy rosszindulatú commitot az actions/checkout actionbe, kihasználva a GitHub fork commit elérhetőségi mechanizmusát. Kicseréltek egy SHA pint a Trivy release workflowjában úgy, hogy egy fork-ban lévő árva commitra mutasson. A commit legitimnek tűnt, a komment azt mondta # v6.0.2, a szerző egy valódi maintainer nevével volt meghamisítva. A tényleges payload Go fájlokat töltött le egy elgépelt domainről és kicserélte a Trivy forráskódját a build során. ...

A múlt héten belefutottam abba, hogy a Kubernetes projekt csendben újraírta az image promotert, vagyis azt az eszközt, ami a hivatalos image-eket feltolja a registry.k8s.io alá. Nem is maga az átírás volt az érdekes, hanem az, hogy az új verzió már rendes SLSA provenance tanúsítványokat és cosign aláírásokat ad az image-ekhez minden tükörnél. Ezen a ponton be kellett vallanom magamnak valamit: a saját image-eimet már jó ideje aláírom CI-ben, de a klaszter oldalon semmit nem kényszerítettem ki. Az aláírás ott volt, csak éppen senki nem nézte. Szóval végre rászántam magam, és rendbe tettem. ...

Múlt héten hajnali 2-kor kaptam riasztást egy payment service-re, ami eldobálta a kéréseket. Az első ösztönöm ugyanaz volt, mint mindig: elő a cluster-admin kubeconfig-gal a csapat wiki oldaláról, aztán nézzük, mi van. Tíz perc alatt megtaláltam a hibát, de másnap reggel a security csapat jelezte, hogy az audit logokban ott virít a session-öm. Jogosan. Az a “temporary” cluster-admin kubeconfig nagyjából nyolc hónapja volt használatban. Szóval végre nekiültem és összeraktam egy rendes debugging workflow-t. Olyat, ami pontosan annyi hozzáférést ad az ügyeletesnek, amennyire szüksége van, pontosan annyi időre, amennyire kell. ...

Egyszer töröltem S3 bucketet, és azóta is bánom. 2022-ben szedtem szét egy staging környezetet, és pár órán belül valaki más már be is húzta ugyanazt a bucket nevet. Egy másik accountban futó CloudFormation stack pedig teljes nyugalommal kezdett logokat írni egy bucketbe, ami már nem az enyém volt. Nem az a péntek volt, amire szívesen emlékszem vissza. Az AWS most végre kiadta a rendes megoldást: account regional namespace az S3 general purpose bucketekhez. Kb. hét év kellett hozzá, ami egyszerre vicces és kicsit fárasztó. ...

A múlt hét nagy részét azzal töltöttem, hogy image pull hibákat vadásztam egy multi-tenant klaszterben. Végül kiderült, hogy a gond a privát registry mirrorunk körül van. Pull-through cache-ként használtuk, de a credentialök node szinten voltak beállítva. Az egyik csapat rotálta a saját hozzáférését, aztán rövid időn belül három másik namespace podjai is elkezdtek hibázni. Ekkor vált teljesen világossá, hogy megosztott credentialökkel próbálunk együtt élni. Innen jutottam el a CRI-O credential provideréhez registry mirrorokhoz. Miután összeraktam, elég nehéz lenne visszamenni a korábbi megoldáshoz. ...

Elegem lett abból, hogy a Grafanához, ArgoCD-hez, Harborhoz és minden más belső toolhoz külön loginokat kelljen kezelnem. Minden új csapattag öt fiók létrehozását jelentette. Minden offboarding azt, hogy reménykedtem, mindegyiket visszavontam. Szóval végre leültem és felraktam a Keycloak-ot a Kubernetes klaszterünkre. Ez az, ami tényleg történt, nem a megszépített verzió. Miért Keycloak Megnéztem a Dex-et, az Authelia-t és a Keycloak-ot. A Dex könnyű, de korlátozott, ha többre van szükséged, mint OIDC proxy. Az Authelia egyszerű setupokra kiváló, de a mi use case-ünkhöz kevés volt. A Keycloak nehezebb, viszont kezeli az OIDC-t, SAML-t, user federation-t, és van rendes admin UI-ja. Egy csapatnak, ami 8+ belső service-t futtat, a súlya indokolt. ...

Két éve futtatom a Falcót runtime securityre a legtöbb klaszteremen. Tette a dolgát, de a kernelmodulos megközelítés mindig törékenynek érződött. Minden kernel frissítésnél benne volt a pakliban, hogy valami eltörik. Amikor a Cilium Tetragon elérte az 1.3-as stabil verziót, tisztán eBPF alapon, kernel modul nélkül, úgy döntöttem, élesben is adok neki egy esélyt. Ez történt. Miért váltottam a Falcóról A Falco jó eszköz, félreértés ne legyen. De újra és újra ugyanazokba a problémákba futottam: ...

Múlt kedden az egyik Go szolgáltatásom egy nap alatt 14 Dependabot PR-t kapott. Ugyanahhoz az egy CVE-hez tartoztak, de a mi futó kódunkat valójában nem érintették. Ettől még végig kellett nézni az alertet, reviewzni a PR-eket, megvárni a CI-t, majd mergelni. Itt döntöttem el, hogy ebben a folyamatban nálunk ennyi volt a Dependabot. Mi volt az utolsó csepp A konkrét eset a CVE-2026-26958 volt a filippo.io/edwards25519 modulban. A sebezhetőség a (*Point).MultiScalarMult metódust érintette, amit a legtöbb projekt nem hív. A javítás is pici volt. Ennek ellenére a Dependabot rengeteg PR-t nyitott Go repókban, még olyanokban is, ahol csak a modul más részeit használták. ...

Tegnap kijött a Kyverno 1.17, a lényeg pedig az, hogy a CEL-alapú policy típusok mostantól GA státuszúak. Ha eddig JMESPath-os ClusterPolicy erőforrásokkal dolgoztál, készülj. Hivatalosan deprecated-ek, és a v1.20-ban (2026 október) kikerülnek. Ma egy teljes napot rászántam egy éles cluster migrálására, amiben kb. 60 szabályzat volt. Így nézett ki a gyakorlatban. Miért fontos ez? A Kyverno évek óta JMESPath kifejezéseket használ. Működnek, de Kyverno-specifikusak. A CEL (Common Expression Language) az, amit maga a Kubernetes is használ a ValidatingAdmissionPolicy-hoz az 1.30-as verzió óta. A CEL-re váltással a Kyverno igazodik az upstreamhez, és érezhetően jobb teljesítményt kap. ...