Opensource DevSecOps tools для DevOps

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Наведені нижче інструменти з відкритим кодом орієнтовані на DevSecOps і можуть бути інтегровані у ваші процедури CI/CD. А що радите ви?

Джерело

Snyk — це developer-first cloud-native інструмент безпеки, який сканує та відстежує ваші проєкти на наявність уразливостей.

OSV від Google — osv.dev — це база даних уразливостей для проєктів з відкритим кодом.

Binskim від Microsoft — це легкий Portable Executable (PE) сканер, який перевіряє параметри компілятора/лінкера та інші бінарні характеристики, пов’язані з безпекою.

Tfsec від Aquasecurity — використовує статичний аналіз вашого коду terraform для виявлення потенційних неправильних конфігурацій.

Trivy від Aquasecurity — комплексний і універсальний сканер безпеки.

KubeLinter аналізує файли Kubernetes YAML і Helm charts і перевіряє їх на відповідність різноманітним кращим практикам, зосереджуючись на готовності до продакшна та безпеці.

Checkov — це інструмент статичного аналізу коду для інфраструктури як коду (IaC), а також інструмент аналізу складу програмного забезпечення (SCA) для зображень і пакетів з відкритим кодом.

ggshield від Gitguardin — це програма CLI, яка працює у вашому локальному середовищі або в середовищі CI, щоб допомогти вам виявити понад 350 типів секретів, а також інші потенційні вразливості безпеки або порушення політики, що впливають на вашу кодову базу.

Теми: DevOps, Security

Ctrl + Enter

Andrii Striletskyi DevOps в Deloitte 25.02.2023 21:52

github.com/renovatebot/renovate — для апдейту депенденсів у випадку секюріті issues, etc

Відповісти

Підтримати

Andrii Striletskyi DevOps в Deloitte 25.02.2023 21:41

CloudCustodian ще є. Теж може різні дії аля cloudcustodian.io/...rdspublicunencrypted.html

Георгий Дерменжи 24.02.2023 16:52

Представник DAST — OWASP ZAP
SEMGREP як альтернатива платному SNYK
Dependency-check для сканів на предмет вразливостей пов’язаних з залежностями
Falco можна налаштувати як своєрідний IDS в к8

Danylo SRE/DevSecOps 24.02.2023 16:34

Для кубера ще ок kube-hunter and kube-bench, секуріті-оркестрація та платформа управління вразливостями — DefectDojo

Pavlo Saikevych Lead DevOps в SoftServe 22.02.2023 11:48

Рекомендую використовувати тули які надаються або безплатно або за мінімальні кошти вашою хмарною платформою. Наприклад для AWS:
GuardDuty, Security Hub, WAF, Inspector

Юрій Ярош developer в bitsnap 24.02.2023 18:23

1. Залежить від маштабу перевірок й ціноутворення нелінійне — навіть до сотні машин ціни трохи бувають кусючі, без передоплати та spot instance’ів.

2. Подібні тули часто завязані на Traffic / Artifact Mirroring та аналіз дампів з object store — мало того що спраьовують з застримкою, так й є певні юридичні моменти з відбілюванням персональних данних.

3. А крім AWS ні в кого нормальних managed сервісів безпеки то й нема... й для оптимізації витрат часто треба в MultiCloud... ще й є додаткова залежність від оранізаційного менеджменту для нормального аудиту доступів. Тобто, якщо компанія хоче в Guard Duty, але не може нормально налаштувати там AWS Organizations, ControlTower (може й через AFT), AWS RAM, й дозволяє всім по IAM’у лазить — то дуже несерйозна компанія... якій відповідний додатковий інструментарій безпеки «магію не принесе». Для орг менеджменту MultiCloud’у там взагалі туман війни — ніхто нічьо не писав, й було б непогано зробити CNCF SIG.

4. Операційні витрати залежать від розуміння що DevOps то не тайтл, а методологія... й кількості DevOps’ів що вміють нормально в Golang, оператори до кубів писати та усілякі провайдери/плагіни до HashiCorp стеку.

5. Ну й операторами/провайдерами усе те OpenSource’не розгортається дуже швидко й зручно... й ризиків із-за більш жорсткого аудиту зазвичай значно меньше — рідше виникає «post mortem». Тобто k8s validating admission policies не дозволить створити ресурс що порушує політики безпеки, та відповідні контролери будуть повинні опрацювати відповідне виключення та зробити дамп історії зміни ресурсів для подальшого аудиту. Тоді як в хмарних оточеннях не забороняється явно створювати будь які ресурси що порушують будь які вимоги безпеки — всі перевірки відкладені.

До 1.26 кубів політики робили на OPA/Kyverno, але зараз намагаються стандартизувати. Так само як AWS намагається стандартизувати IAM через Cedar під Verified Permissions / Access. Краще вже, як й всі білі люде, там адаптували б IAM під Rego або CUE... чи то 15 стандартів чи то Special Snowlakes... мабудь я чогось не розумію (розпилу бюджету ентерпрайсів рішеннями з примарною цінністю).

Pavlo Saikevych

Pavlo Saikevych Lead DevOps в SoftServe 24.02.2023 18:46

З мого досвіду: мулютиклауд лише на папері та в теорії дешевший, а в реальності завжди дорожчий, більше людей потрібно на підтримку, важче щось імплементувати нове, важче дебажити, важче онбордити. Якщо використовувати один клауд і меншу кількість інструментів, то й оптимізувати легше. Найпоширеніша помилка яку бачу — юзати куб скрізь де треба і не треба. Не всі проєкти це нетфлікс чи щось подібне, 90%+ проектів це B2B де навантаження не такі вже високі. Також часто можна використати Серверлесс і взагалі немати докеру і контейнерів.

Юрій Ярош

Oleksandr Savchenko DevOps Engineer 24.02.2023 23:47

Якраз юзати куб де попало це нормальна стратегія. Бо куб він один, а всяких аналогів ламбд — багато.

Pavlo Saikevych Lead DevOps в SoftServe 25.02.2023 06:40

Тоді й кости будуть відповідні.
Вже не один раз бачив що в куб, на окремі контейнери які 24/7 раняться, всовують те що там не має бути:
— Статика
— АПІ
— БілдАгенти
— Окремий Кеш/логування
І це ще дублюється для dev/qa/prod і потім, навіть для невеликого проєкту, який ще і толком клієнтів немає, виходить цінник 10тис$ на місяць за інфру.
А можна було, наприклад використати: s3bucket+CloudFront, API Gateway, CodeBuild і інші сервіси, або відповідні аналоги якщо у вас інший клауд.
Якщо є Куб + ще й мультиклауд + різні окремі тули для логів&кешу&ssl&etc , я Ні разу, не бачив, щоб на тому проєктs був лише один девопс. Складність дуже швидко зростає і потім, наприклад, для 20 девів потрібно 5 девопсів, замість одного.
Виж якщо використовуєте куб і мультиклауд, то напевне і Логування+моніторинг має вже бути не в КлаудВотч а в ’клаудагностік’ тулі. Так само і кеш і решта.

Oleksandr Savchenko

Oleksandr Savchenko DevOps Engineer 25.02.2023 07:20

Managed kubernetes це не так вже дорого, $0.1/h. Цінник на compute залишається тим самим.
Щодо іншого, то вам що, лямбди чи наколгопслені анзібл деплойменти моніторити не треба? Ну так і на контейнери в кубернетесі можна економно забити. Той самий клаудвотч однаковий як для колгоспу, так і для кубера, тільки для кубера все давно вигадано, включно з сервіс діскавері і тд, а колгосп треба ще якось прикручувать. Щодо статики і тд, то ж ніхто не забороняє s3 використовувати для відповідних задач. Storage, cdn і compute це таки різні речі. Ну і ціна serverless на якомусь етапі швидко перевищує відповідну ціну на задач на self-managed ec2. Плюси кубернетеса в тому, що він стандартний. Так, поріг входу високуватий, але коли воно по уму зроблено, в нас під то під сотню команд непогано справляються.

Pavlo Saikevych Lead DevOps в SoftServe 25.02.2023 07:29

Ви мене переконали що потрібно робити доповідь на тему: Don’t use Kubernetes))
Чи можна його нормально використовувати? Звісно що так. Моя позиція у тому, що це відбувається набагато рідше ніж хотілося б

Юрій Ярош developer в bitsnap 25.02.2023 21:07

Питання накопичених практик, організаційної зрілості, та готовності розробки / підтримки відповідних OSS рішень. В нас же люде на Kubecon не катають та у СNCF SIG’ах участі не приймають — аутсорсам же ж «то грошей не приносить».

Коли є компанії що продають Ad Hoc як Agile, й то ще хтось може сприймати... на будь яку адекватність, професійний розвиток, та просто сприйняття оточуючого світу, сподіватись не доводиться... а DevOps / Куби карго-культ, мало чим відрізняється від Agile років 5-8 тому, — так само продають базворди.

Юрій Ярош developer в bitsnap 25.02.2023 21:01

Managed kubernetes це не так вже дорого, $0.1/h.

Є купа обмежень, особливостей, поновлення кубів як нормально не працювали, так й не працюють... й по складності керування — самохостяні куби на віртулаках безпечніше й гнучкіше.

EKS Fargate там не вміє в EBS, й не хоче вміти... по чисто політичним причинам — Амазон не хоче втрачати гроші. Й таких кейсів конкретно з керованими сервісами, особливо з базами данних, забагато.

Були випадки коли й DynamoDB обходився до 100К в тиждень — злізли на Scylla й ніхто ніколи таких цінників не бачив... була відповідальна команда й відповідальні люди, а не «буде в нас managed, бо Амазон подбає...». Платили потім за підтримку Scylla, але в тому було на багато більше профіту з точки зору бізнесу, окрім самої оптимізації витрат.

Позиція «то ж не твої гроші» безвідповідальність персоналу не виправдовує...

наколгопслені анзібл деплойменти моніторити не треба?

Ансібл годиться зараз Лише для налаштування віртуалок під Packer’ом... з Container Linux дистрибутивами по типу FlatCar / Bottlerocket / CoreOS й роздачею рутових прав через Сapabilities, в усіх puppet / chef / ansible просто відпала необхідність.

Юрій Ярош developer в bitsnap 25.02.2023 20:53

З автоскейлінгом у кубів є проблеми бо треба відмовлятись від HPA та використовувати щось на кшталт Keda з кастомними метриками. Той же Karpenter мало хто може нормально налаштувати...

я Ні разу, не бачив, щоб на тому проєктs був лише один девопс.

3-4 — максимум, й зазвичай один й той же стек повторно використовується на 50-80 клієнтів...

А можна було, наприклад використати: s3bucket+CloudFront, API Gateway, CodeBuild і інші сервіси, або відповідні аналоги якщо у вас інший клауд.

Можна, але
CodeBuild не найшвидша штука, й для ряду завдань з автоскейлінгом build/test кластерів не підходить (коли білдять на bazel чи buildkit в кластерах воркерів, що актуально для складних мікрофронтендів та великих нативних мобільних додатків).
CloudFront як СDN дуже дорогий порівняно з CloudFlare, та відповідно для A/B тестів на Lambda Edge там цінник взагалі кінський виходить (10К$ в добу vs 700$ в добу).
S3 можна використовувати тільки з конкретними політиками архівування в Glacier та розділяти обєкти по різним Storage Tier’ам.

Нажаль ВСІ існуючі сервіси AWS не можна назвати надійними, й в ряді випадків то занадто великий бізнес ризик... є окремі види страхування прибутків на випадок смерті хостингу.

Якщо DevOps’и криворукі та не можуть налаштувати, або ж виправити/дописати інструментарій, менеджмент й керівники не знають як розставити пріорітети та відмовляються керувати ризиками, а програмісти відмовляються проходить CKAD, який проходять школярі при поглибленому вивченні операційних систем... то Куби в тому точно не винні.

Cкільки на ринку DevOps’ів з практичними навичками Golang для виправлення вад HashiCorp / Kubernetes тулів якими ж й користуються, а як щодо реалізаціх операторів на Golang під k8s API ?... то може проблема в підміні понять ?... в тому що DevOps — то методологія, а не посада ?

Oleksandr Savchenko DevOps Engineer 25.02.2023 21:36

Той же Karpenter мало хто може нормально налаштувати...

Та госпаді, що там в ньому налаштовувати? Цікавлюсь бо використовую його в проді вже десь рік, в 20-30 кластерах, без особливих нарікань, бо то шикарна річ, я б сказав гейм чейнджер.

Cкільки на ринку DevOps’ів з практичними навичками Golang для виправлення вад HashiCorp / Kubernetes тулів якими ж й користуються

Мало, зазвичай в цьому сенсу немає, бо правильно — це слати багрепорти. Та і, відверто кажучи, баги в кубернетес ви не кожен день знаходите.

а як щодо реалізаціх операторів на Golang під k8s API

А ось тут ви ставите виправляння багів в кубернетес на один рівень з гівнокодингом операторів на 90% згерерованих за допомогою opertator-sdk. Що є абсолютно посильною задачею для девопса, який дочитав книжку по го десь до середини. Бо ніякого рокет саєнсу там немає.

Юрій Ярош developer в bitsnap 25.02.2023 21:54

Та госпаді, що там в ньому налаштовувати?

Amazon Linux та Ubuntu «нормальними» давно не вважаються, а під Bottlerocket не осилюють в UserData прописати налаштування eviction’у та provisioner’а ... ноди до сих пір нормально не дрейняться з видаленням Provisioner’а та Capacity Spread не можуть налаштувати нормально (хоча б вручну, бо karpenter не вміє).

бо правильно — це слати багрепорти.

Їх або виправляєш сам, або їх виправляють через 3-4 місяці 2-7 років, а клієнтам треба зараз. Або ж не виправляють взагалі по політичним причинам.

з гівнокодингом операторів на 90% згерерованих за допомогою opertator-sdk.

Я кажу не конкретно про баги, а наприклад про виправлення вад там якоїcь абстрактної реалізації Cluster API або Gateway API, виправлення вад дизайну якихось Terraform провайдерів, тощо...

Проблема кодогенератору Operator SDK в тому що він оперує kubebuilder’ом як лібою — якщо то все робити вручну з відповідними плагінами, зайве завше можна видалити.
Загалом дизайн що Operator SDK що OLM вважають дуже кривим, навіть у самій RedHat, й частіш більше толку від чогось простого типу Metacontroller, навіть під knative.

Oleksandr Savchenko DevOps Engineer 26.02.2023 00:00

таке відчуття що тут користувач сяомі доводить чому айфон поганий.
По темі. Наші ноди на bottlerocket. Видалення провіжененера і дрейн нод ніяк не повинні бути пов’язані. run k delete no -l і видаляй cr provisioner. Capacity speread — хз що ви тут мали на увазі.

Проблема кодогенератору Operator SDK

це не проблема. Operator SDK, kubebuilder — це інструмент який зробить за тебе 90% роботи, а твоя справа лише бізнес логіку договноколить. І мені тупо пофігу на «все зайве», ну от взагалі. Як і 99% користувачів цього інструменту.

виправлення вад там якоїcь абстрактної реалізації Cluster API або Gateway API

Ват? Правки в кластер апі етс? І хто через два роки буде розбиратися з вашим очумєлимі ручками і тим що нафоркали і надеплоїли в прод, коли ви вже рік як звалили? Як оновлюватися? Більшої свині для бізнесу навіть уявити важко.

Юрій Ярош developer в bitsnap 26.02.2023 12:48

хз що ви тут мали на увазі.

[1]
[2]

І мені тупо пофігу на «все зайве», ну от взагалі. Як і 99% користувачів цього інструменту.

Ну вам пофігу, red hat’у там не пофігу, — в них Community Adoption дуже поганий...

І хто через два роки буде розбиратися з вашим очумєлимі ручками і тим що нафоркали і надеплоїли в прод, коли ви вже рік як звалили?

Це контрібьют, а не форк зазвичай...

Більшої свині для бізнесу навіть уявити важко.

Залежить від організаційної зрілості, та контролю якості — й на куби ж є E2E тести...

Oleksandr Savchenko DevOps Engineer 27.02.2023 03:39

Ще раз: враховуючи що провіженери видаляються не кожен день, ніщо не заважає "k delete node -l перед його видаленням. Але так, це мінорний косяк, його виправлять. Під сapacity spread ви мали на увазі topology spread constraints, то також ок.

Ну тут без коментарів взагалі.

Щодо контрібьюшинів, то ну камон, в тебе 4 репи форкнуті, і менше сотні contributions в GitHub за минулий рік. З яких пул реквестів — два, інші це коментарі. Нахіба ці дешеві понти, кому ти щось доводиш?

Юрій Ярош developer в bitsnap 27.02.2023 11:43

Але так, це мінорний косяк, його виправлять.

Якщо таких косяків під сотню — то може зайняти забагато часу, моє твердження в тому що DevOps’и мають вміти те робити, щоб хоча б виправляти критичні вади.

Щодо контрібьюшинів, то ну камон, в тебе 4 репи форкнуті, і менше сотні contributions в GitHub за минулий рік.

Можна на особистості не переходити ?

Нахіба ці дешеві понти, кому ти щось доводиш?

Я особистно не бачу сенсу контрібьютити те що не впливає значним чином на ціьові продукти й спільноти, та просто не витрачаю на те часу.

Зараз мене сильно розчарував стан HashiCorp екосистеми після виходу й провалу IPO.

Юрій Ярош developer в bitsnap 25.02.2023 20:40

Не зовсім так, — лямбди намагались не раз стандартизувати, й завше виходило погано (serverlessworkflow під Dapr тощо). Зараз частіш просто роблять Knative сумісний рантайм під AWS (KLR тощо), та відповідно Cloud Run й так Knative... з ажуром також якось вирішується, але в них й так їхні функи на кубах працюють й по ціні від самохостяного KNative не відрізняються (питання предоплати, спотів та ефективного автоскейлингу).

Куби дійсно пихають куди завгодно особливо через Cluster API, й то має великі переваги для ML’я бо частіш дешевше навчить модель десь на GCP, а прод ганяти на AWS.

З урахуванням нелінійного ціноутворення AWS, й майже лінійного, але не дуже на GCP/AWS, разом з періодичними відвалами мережі та сервісів — завше треба тримати «План Б». Ну тобто надійність aws us-east-1 вже давно мем.

Якщо «для когось дорого», або «складно онбордити» — то значить організаційна зрілість компанії та кваліфікація не дотягує трохи щоб його «нормально готувати», а не «мультиклауду не бачив — значить ніде його й нема».

Треба розуміти що 99% ніасіляторів кубів на ринку просто відають роботу індусам зі ставками по 80$/hr за налаштування на рівні «просто візьми helm chart».

Opensource DevSecOps tools для DevOps

21 коментар

Підписатись на коментарі