Ahoj, mám dotaz: jsme bezpečnostní firma, zaměřujeme se primárně na ochranu enterprise sítí (velký společnosti, telco, armáda, kritická infrastruktura) a jsme v tom myslím docela dobrý. Technologický partner, se kterým děláme a jehož řešení používáme, před rokem koupil společnost Twistlock, kterou přibral do portfolia a rozšiřuje tak služby i na oblast DevSecOps, ochranu kontejnerů a serverless. Hledáme někoho, koho zajímá oblast bepzečnosti v prostředí kontejnerů a kdo by byl ochotný poslechnout si jak tato oblast produktů funguje, případně dostal demo na vyzkoušení a probral s námi, zda je taková ochrana skutečně přidanou hodnotou a zda by něco takového používal.
Odměnou může být nějaká dlouhodobější spolupráce na projektech, možnost pořízení nástroje do firmy se zajímavou slevou, posun do oblasti DevSecOps atd. Případně se dá domluvit i na placeném otestování jako službě.

Elevator pitch:
Nástroj umožňuje zabezpečení celého životního DevOps cyklu, a to pro všechny běžně využívané platformy, aplikace i cloud prostředí (např. Docker, Kubernetes, GCP, Azure, AWS i Openshift). Mezi zásadní dostupné funkce patří mimo jiné:
1. Vulnerability Management – automatický nástroj pro zjišťování známých zranitelností napříč všemi hosty, kontejnery i funkcemi serverless computingu.
2. Cloud Native Firewall – integrovaný L4 a L7 firewall v prostředí Kubernetes, zajišťující vhled do síťové komunikace mezi kontejnery a mikroslužbami na úrovni aplikací, funkci IPS a mikrosegmentaci.
3. Runtime Defense – behaviorální analýza a automatizovaná detekce i prevence incidentů v prostředí kontejnerů.
4. Access Control – centrální monitoring Kubernetes, auditování hostů, inspekce logů a monitoring příkazů docker, sshd a sudo events.
5. CI/CD integrace – skenování vulnerabilit při zavádění nového kódu v CI/CD pipeline, např. prostřednictvím modulu do nástroje Jenkins.

Nesnažím se tu teď nic prodávat, jde mi vážně o možnost spolupráce a dostat od někoho z oboru reálný feedback. Kdyžtak pošta prosím.

Disclaimer: nikdo z nás není developer :-)

ONLINEQUE: disclaimer, jsem dlouho vyvojar a castecne uz fusuju i k adminum (protoze nasi admini se virtualizace boji) .. troufam si tvrdit, ze "developeri jsou lenivi" je hodne zjednodusene videni sveta, ktere Ti asi moc nepomaha, ne? dovedu si predstavit a zcela chapu, ze to bude platit v "nizsich urovnich" hierarchie, protoze jsou to juniori a maji uplne jine problemy a jinou perspektivu .. ale technicky dluh je problem stejne tak administratoru, jako vyvojaru, takze u nas treba tohle pada na hlavu seniornich programatoru ..

vize, kterou mame o tom, jak to adminum predame, je, ze si programatori reknou 'parametry', ktere ten image musi splnovat (aka musi tam byt napr JAVA_HOME, musi tam byt nahrane JDK 8+ na ktere JAVA_HOME ukazuje, a instalovane ssh + curl a verejne certifikacni autority, a uzivatel musi mit nahrany konkretni ssh klic) .. senior vyvojari pak vyjdou z takoveho image, nahraji si tam treba AS (tomcat, wildfly, nastavi ho aby se spoustel, atp) .. a tim vznikne "dev base image" ktery pouzivaji juniori, protoze tam maji to co potrebuji, jen si tam mountnou treba adresar se zdrojakama, rozsiri si ho o debug nastroje atp .. do produkce ale pujde ten baseimage od seniora s otestovanou a otagovanou verzi ..

Diky vsem za prinosnou debatu ;-), tim jsem asi tema vycerpal ;-}

ONLINEQUE: hele je to tak, zvlast pokud potrebujete veci ktery se blbe automatizujou. V my aktualni praci mame problem "podobnej" a realita je takova ze jsem na to tymu napsal sadu fire-and-forget utilitek, ale tu posledni mili s commitem do interniho repa proste musi udelat nakej clovek. Dulezity je mit na to dobrej proces a zbavit se veci co trvaji a jsou otravny, a pak to proste brat jako development effort.

ONLINEQUE: Budto na to mate automation (jakoze nightly upstream sync) a nebo na to mate cronjob co kazdou druhou nedeli udela ticket nahodny obeti a nezavre ho dokud obet nereleasne novej image :)

ONLINEQUE: zkusil sis rozepsat strom zavislosti a podle toho se podivat jestli muzes verzovat zavislosti a ty finalni kontejnery upgradovat podle toho?

ADM: Problem kontejneru ktery si muzes menit je, ze ti vytvari heterogenni prostredi a hrozne blbe se pak hledaj rozdily a problemy.
Pro development, whatever. Ale pokud jdes do nightly runu (a dal) s tim, ze si postavis container stack a pred startem aplikace tam musis na cokoliv sahnout (as opposed to just injecting configuration from the driver), tak ten image neni udelanej spravne - IMHO. Jasne, da se to udelat spoustou veci, muj osobni nazor je ze pokud aplikacni kontejnery musis modifikovat za behu, zadelavas si na problemy v produkci :)

ADM: "aplikacni kontejnery existuji prave od toho, aby se tam ten pip install, mohl delat"
je to trosku slovickareni, ale pip install mam v dockerfilu a ten mi vybuildi image, potud ok ... kdyz ten image pak pustim tak mam kotejner a v nem uz se pip install fakt nepousti