Opensource DevSecOps tools для 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 типів секретів, а також інші потенційні вразливості безпеки або порушення політики, що впливають на вашу кодову базу.
21 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарівgithub.com/renovatebot/renovate — для апдейту депенденсів у випадку секюріті issues, etc
CloudCustodian ще є. Теж може різні дії аля cloudcustodian.io/...rdspublicunencrypted.html
Представник DAST — OWASP ZAP
SEMGREP як альтернатива платному SNYK
Dependency-check для сканів на предмет вразливостей пов’язаних з залежностями
Falco можна налаштувати як своєрідний IDS в к8
Для кубера ще ок kube-hunter and kube-bench, секуріті-оркестрація та платформа управління вразливостями — DefectDojo
Рекомендую використовувати тули які надаються або безплатно або за мінімальні кошти вашою хмарною платформою. Наприклад для AWS:
GuardDuty, Security Hub, WAF, Inspector
З мого досвіду: мулютиклауд лише на папері та в теорії дешевший, а в реальності завжди дорожчий, більше людей потрібно на підтримку, важче щось імплементувати нове, важче дебажити, важче онбордити. Якщо використовувати один клауд і меншу кількість інструментів, то й оптимізувати легше. Найпоширеніша помилка яку бачу — юзати куб скрізь де треба і не треба. Не всі проєкти це нетфлікс чи щось подібне, 90%+ проектів це B2B де навантаження не такі вже високі. Також часто можна використати Серверлесс і взагалі немати докеру і контейнерів.
Якраз юзати куб де попало це нормальна стратегія. Бо куб він один, а всяких аналогів ламбд — багато.
Тоді й кости будуть відповідні.
Вже не один раз бачив що в куб, на окремі контейнери які 24/7 раняться, всовують те що там не має бути:
— Статика
— АПІ
— БілдАгенти
— Окремий Кеш/логування
І це ще дублюється для dev/qa/prod і потім, навіть для невеликого проєкту, який ще і толком клієнтів немає, виходить цінник 10тис$ на місяць за інфру.
А можна було, наприклад використати: s3bucket+CloudFront, API Gateway, CodeBuild і інші сервіси, або відповідні аналоги якщо у вас інший клауд.
Якщо є Куб + ще й мультиклауд + різні окремі тули для логів&кешу&ssl&etc , я Ні разу, не бачив, щоб на тому проєктs був лише один девопс. Складність дуже швидко зростає і потім, наприклад, для 20 девів потрібно 5 девопсів, замість одного.
Виж якщо використовуєте куб і мультиклауд, то напевне і Логування+моніторинг має вже бути не в КлаудВотч а в ’клаудагностік’ тулі. Так само і кеш і решта.
Managed kubernetes це не так вже дорого, $0.1/h. Цінник на compute залишається тим самим.
Щодо іншого, то вам що, лямбди чи наколгопслені анзібл деплойменти моніторити не треба? Ну так і на контейнери в кубернетесі можна економно забити. Той самий клаудвотч однаковий як для колгоспу, так і для кубера, тільки для кубера все давно вигадано, включно з сервіс діскавері і тд, а колгосп треба ще якось прикручувать. Щодо статики і тд, то ж ніхто не забороняє s3 використовувати для відповідних задач. Storage, cdn і compute це таки різні речі. Ну і ціна serverless на якомусь етапі швидко перевищує відповідну ціну на задач на self-managed ec2. Плюси кубернетеса в тому, що він стандартний. Так, поріг входу високуватий, але коли воно по уму зроблено, в нас під то під сотню команд непогано справляються.
Ви мене переконали що потрібно робити доповідь на тему: Don’t use Kubernetes))
Чи можна його нормально використовувати? Звісно що так. Моя позиція у тому, що це відбувається набагато рідше ніж хотілося б
Та госпаді, що там в ньому налаштовувати? Цікавлюсь бо використовую його в проді вже десь рік, в20-30 кластерах, без особливих нарікань, бо то шикарна річ, я б сказав гейм чейнджер.
Мало, зазвичай в цьому сенсу немає, бо правильно — це слати багрепорти. Та і, відверто кажучи, баги в кубернетес ви не кожен день знаходите.
А ось тут ви ставите виправляння багів в кубернетес на один рівень з гівнокодингом операторів на 90% згерерованих за допомогою opertator-sdk. Що є абсолютно посильною задачею для девопса, який дочитав книжку по го десь до середини. Бо ніякого рокет саєнсу там немає.
таке відчуття що тут користувач сяомі доводить чому айфон поганий.
По темі. Наші ноди на bottlerocket. Видалення провіжененера і дрейн нод ніяк не повинні бути пов’язані. run k delete no -l і видаляй cr provisioner. Capacity speread — хз що ви тут мали на увазі.
це не проблема. Operator SDK, kubebuilder — це інструмент який зробить за тебе 90% роботи, а твоя справа лише бізнес логіку договноколить. І мені тупо пофігу на «все зайве», ну от взагалі. Як і 99% користувачів цього інструменту.
Ват? Правки в кластер апі етс? І хто через два роки буде розбиратися з вашим очумєлимі ручками і тим що нафоркали і надеплоїли в прод, коли ви вже рік як звалили? Як оновлюватися? Більшої свині для бізнесу навіть уявити важко.
Ще раз: враховуючи що провіженери видаляються не кожен день, ніщо не заважає "k delete node -l перед його видаленням. Але так, це мінорний косяк, його виправлять. Під сapacity spread ви мали на увазі topology spread constraints, то також ок.
Ну тут без коментарів взагалі.
Щодо контрібьюшинів, то ну камон, в тебе 4 репи форкнуті, і менше сотні contributions в GitHub за минулий рік. З яких пул реквестів — два, інші це коментарі. Нахіба ці дешеві понти, кому ти щось доводиш?