Нашли картинку, которая наглядно изображает, как с помощью инструментов DevSecOps автоматизировать рабочую рутину. Машина Голдберга, которую мы все заслужили 🤓 Всем хорошей и продуктивной пятницы: https://twitter.com/memenetes/status/1287923648787931136?s=09

И снова привет!

Недавно наткнулись на агрегированную подборку материалов по DevOps. Она включает в себя информацию о различных решениях (зачастую и в большей степени open source), которые могут пригодиться для таких задач, как:

🍭 Code review
🍭 Chat and Chat Ops
🍭 Chaos Engineering (куда уж без этих 🙈)
🍭 Secret Management
🍭 Monitoring
🍭 И многое другое :) Позиций и правда больно много, чтобы все перечислять

В дополнение, помимо технологий, есть ссылки на полезные ресурсы (книги, конференции) и... DevOps Roadmap - прямо путь самурая путь DevOps'era с указанием компетенций, которые ему надо развить - хоть на стену вешай!!!
Кстати, а согласны ли вы с таким развитием специалиста? Ждем вас в чате для обсуждения!

Ссылка на Awesome DevOps: тут! Всем отличного дня!

GitHub
wmariuss/awesome-devops
A curated list of awesome DevOps tools, platforms and resources - wmariuss/awesome-devops

Что делать, если хочется Infrastructure as a Code, а вся инфраструктура уже развернута? Встречайте Terraformer - CLI для анализа существующей инфраструктуры и автоматической генерации tf и tfstate, aka reverse Terraform.

Помимо крупнейших облаков умеет работать с Yandex.Cloud, OpenStack, Kubernetes и много чем ещё. VMware не умеет :( есть issue, но без движения с апреля.

Вот тут можно посмотреть пример работы.
“Infrastructure to Code: Terraformer” by Amet Umerov https://link.medium.com/VHHyplG1D8

Привет!

Решили познакомиться с новыми CI/CD инструментами (не Jenkins’om единым!) и наткнулся на интересную статью про … Docker!!! А именно – antipatterns и как можно их избежать.

У автора интересная подача, которая начинается с простого – «Не путайте виртуальные машины и контейнеры. Контейнеры – не виртуальные машины!». Не с точки зрения техники, скорее с точки зрения восприятия. Это важно, потому как это подводит к таким советам, как:

🍭 Образ контейнера – новая «единица обмена» информацией. Dev больше не дает код/приложение Ops и не просит его «развернуть». Он дает Dockerfile!

🍭Образы должны быть максимально простыми. И даже образы контейнеров можно «дробить» (есть интересный подход через multistage build, где результирующий Dockerfile не содержит «лишней» информации, что делает его легче, менее многослойным)

🍭 Не «вшивайте» конфигурационную информацию ИТ-окружения в Dockerfile – это подводит нас к тому, что Dockerfile в Dev, Test, QA, Cert, Pre-prod и Prod – это один и тот же образ!

🍭 А как тогда передать конфигурацию?.. В run-time, например, в качестве переменных окружения - в статье есть отличные примеры и инструменты, которые позволяют это делать!

И это далеко не все (согласно рекомендациям, статья занимает 19 минут)!

Всем привет!

Снова возвращаемся к теме управления секретами.
Хардкодить пароли в конфигах и образах плохо? Выносить их в переменные окружения лучше, но тоже плохо? Что же тогда делать?
Использовать систему управления секретами!
В этот раз расскажем немного о CyberArk Conjur.
Conjur - это open source версия коммерческого продукта Cyberark DAP (Dynamic Access Provider). Он разворачивается в среде контейнеризации, например, и реализует функции работы с секретами.

Что она делает на пальцах: Conjur хранит в зашифрованном виде значения секретов в своей БД. Эти значения она может выдать только верифицированным объектам (пользователям, сервисам и т.д.), подтвердивших свою легитимность сертификатом. Если получателю можно выдать секрет, то он будет переслан в зашифрованном виде через TLS подключение, а потом инжектирован в переменную окружения.

Стоп, скажете вы, но ведь все равно в переменную окружения, в чем тогда смысл?!
А смысл в том, что в отличие от простого хранения секрета внутри переменной, Conjur обеспечивает их плановую ротацию. В дополнение к этому, он ведет аудит всех действий над секретами, будь то их выдача или обновление. Таким образом, в любой момент времени можно узнать какое действие, кем и над каким секретом было осуществлено.
К тому же, Conjur гарантирует выдачу секрета только разрешенным получателям с валидным сертификатом.

Чем может помочь Conjur :
🍩 Пароли хранятся за пределами приложений и контейнеров
🍩 Система гарантирует что секрет будет выдан только по валидным запросам
🍩 Система ведет аудит всех действий над секретами (внесение, обновление, выдача)
🍩 В enterprise варианте возможно создание отказоустойчивого кластера
🍩 Легкая интеграция с CI/CD системами и оркестраторами
🍩 Централизованное управление секретами
И многое другое.

Подробнее - на портале вендора.
https://www.conjur.org/

Привет! Ещё одна вундервафля от Red Hat: на этот раз глобальный балансировщик на несколько кластеров OpenShift. Интегрируется с ACM, но поддерживает пока только ExternalDNS и Амазон, а значит не очень практически применима. Но концепт интересный, плюс пойдет в виде ликбеза и лучших практик.

https://www.openshift.com/blog/global-load-balancer-for-openshift-clusters-an-operator-based-approach

Всем привет! Если у вас приложение развёрнуто в RedHat OpenShift и ему требуется доступ к системам и СУБД вне кластера, то вы наверняка задумывались о том, как выпустить нужный тип трафика наружу, причём так, чтобы не открывать доступ со всех узлов кластера.

Чтобы решить эту задачу, можно использовать несколько способов. По сути каждый из них сводится к тому, чтобы выделить приложению конкретный адрес сети хоста, который затем указать на корпоративных СЗИ типа NGFW, proxy и пр. Тем не менее, каждый способ имеет свои особенности.

🍡Способ 1. Назначить egress IP (адрес из подсети узлов кластера) на ноды, затем присвоить этот адрес конкретному проекту (namespace). Это делается в 2 команды на уровне oc. Затем OpenShift сам поднимает дополнительный интерфейс и перекидывает egress IP в случае падения ноды.

После настройки трафик из подов проекта к внешним системам будет идти не с "обычного" IP хоста, а с выделенного egress IP. Этот адрес затем можно использовать на "типовых" средствах защиты в качестве source-адреса. Кроме этого можно на уровне самой платформы настроить EgressNetworkPolicy, которая позволит ограничить то, куда приложение может ходить. Но у неё, увы, есть ряд серьёзных ограничений. Для версии 4.5 это актуальный способ и по факту является заменой egress router (об этом ниже). Более подробная информация тут.

🍡Способ 2. Поднять в поде дополнительный интерфейс (отдельная сеть). Этот относительно новый подход, который может использоваться не только для контроля внешнего трафика (скорее, так просто можно делать), но и для разделения потоков трафика приложения. Реализуется эта возможность с помощью "мета" CNI-плагина, который называется multus. Multus - это open source проект, который умеет 'дёргать' другие плагины. Он и обеспечивает 'attach' дополнительного интерфейса в под. У RedHat OpenShift есть следующие плагины, которые можно дёргать multus-ом: bridge, host-device, macvlan, ipvlan, SR-IOV. Более подробно можно почитать тут и тут.

🍡Способ 3. В более старых версиях RedHat OpenShift, например, 3.11, можно еще развернуть egress router (под+сервис). Egress router разворачивается на конкретной ноде, ему тоже требуется выделенный IP. Egress router может работать в 3-х режимах (DNS proxy, HTTP/S proxy, redirect), выбор которого зависит от типа передаваемого приложением трафика. В конфигах настраивается source, destination, gateway. В этом случае надо сделать так, чтобы приложение подключалась к сервису egress router для доступа к внешним ресурсам. Этот вариант исчез из документации в 4.5. Для 3.11 описан тут.

Привет!

17 августа CNCF провела несколько онлайн сессий в рамках KubeCon: ServiceMeshCon, Serverless Practitioners Summit и Cloud Native Security Day.

Буквально вчера на youtube стали доступны записи докладов!!! Посмотреть их можно по ссылке. А чтобы получить первое представление о том, что можно посмотреть приводим несколько примеров:

ServiceMeshCon:

🍭 Service Mesh Is Still Hard. The Things we all Did Wrong & Tales of Woe
🍭 Service Mesh Architectures Explained - Sidecar and Beyond

Serverless Practitioners Summit

🍭 Chaos Engineering in a Serverless World 🙈🙈🙈
🍭 3factor app: An Accessible Design Pattern for Serverless

Cloud Native Security Day

🍭 Kubernetes Attack and Defense
🍭 Pod Security as an Afterthought

Что может быть лучше, чем залезть под одеяло в такую погоду и смотреть множество интересных видео?
А какой доклад понравился вам больше всего? Ждем в чате! Кстати, там даже есть доклад от Сбербанка 😃

Привет!

Читая большое количество статей про Kubernetes и контейнеры может сложиться впечатление, что это просто silver bullet, который позволяет без особых усилий переносить приложения всеми возможными способами (из Dev в Prod, из on-prem в Cloud, из Cloud в on-pem и вообще везде-везде-везде).

Но, все знают, что silver bullet не существует, но продолжают его искать. Такой вот парадокс. Чтобы показать, что реальность может несколько отличаться от ожиданий мы перевели отличную статью Kevin Casey, в которой рассматриваются потенциальные трудности (или задачи! зависит от вашей точки зрения), с которыми можно столкнуться при миграции Dev -> Prod!

А вы сталкивались с чем-нибудь подобным или все прошло «как по маслу»? Ждем вас в чате!

https://habr.com/ru/company/jetinfosystems/blog/518694/

Всем привет!

К вопросу о сетевых плагинах к Kubernetes. Нашли отличную статью про актуальные плагины для кубера, в которой приведено сравнение по производительности для разных вариантов. На наш взгляд, весьма ценная информация, которая позволяет сориентироваться в существующем многообразии CNI. Помимо тестов на performance, авторы так же дают рекомендации по настройке MTU, и рассматривают вопрос функционирования при включении шифрования трафика. Рекомендуем к прочтению!

https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-10gbit-s-network-updated-august-2020-6e1b757b9e49

Привет!

По ссылке пост из блога компании Palo Alto Networks, который описывает, казалось бы, достаточно очевидные вещи, такие как значимость комплексного подхода для защиты контейнеров.

Суть заключается не только в анализе образов, но и в защите runtime. Такой подход позволит стать ближе к реализации концепции Zero Trust в Cloud Native мире. А сами примеры того, на что стоит обращать внимание приведены в статье! ) Приятного чтения!

Ссылка: https://blog.paloaltonetworks.com/2020/09/cloud-native-zero-trust/

И это снова мы!

В предыдущем посте мы написали про значимость комплексного подхода по защите контейнеров: на «уровне» образов и runtime. А так ли это важно на самом деле?

Ответ – да. Из показательных примеров можно привести недавно обнаруженную уязвимость CVE-2020-14386, которая позволяет повысить привилегии до root и совершить escape на node.

Специалисты из Sysdig написали потрясающую статью, которая описывает способы обнаружения и устранения указанной уязвимости с использованием их продуктов:

🍭 Falco (runtime защита) – создание правила, которое позволит идентифицировать создание новых socket в контейнер
🍭 Sysdig Secure – использование функционала по анализу workloads с целью идентификации тех, что подвержены рассматриваемой CVE

Для устранения уязвимостей рекомендуется следующее:

🍭 Обновить операционную систему
🍭 Отключить CAP_NET_RAW
🍭 Использовать PodSecurityPolicy

Для последнего отлично подойдет Sysdig Secure PSP Advisor, который позволяет «эмулировать» применение политики для идентификации workloads, которые будут подвержены изменениям, что позволяет минимизировать нежелательный эффект (например, нарушение доступности) при применении политик!

Подробности и примеры можно найти по ссылке: https://sysdig.com/blog/cve-2020-14386-falco/

Всем привет! 22 сентября вышла новая версия Prisma Cloud Compute Edition компании Palo Alto Networks. Версия 20.09.345.

Перечень основных изменений:
🍡 Появилась поддержка VMware Tanzu TAS
🍡 Сканирование git-репозиториев на наличие уязвимых компонентов
🍡 Возможность настройки правил для конкретных кластеров (а не только образов, хостов и пр)
🍡 Добавление новых методов аутентификации (OAuth 2.0 and OpenID Connect)
🍡 Расширение функциональности Web Application Firewall (теперь модуль CNAF называется WAAS)

С полным перечнем изменений можно ознакомиться тут.

Всем привет!

Решили у вас спросить, какие посты вы хотели бы видеть в нашем канале DevSecOps Talks, поэтому составили короткий опрос. Собираем ваши мнения 😊

Привет!

Спасибо всем, кто принял участие в нашем опросе. Мы точно будем писать больше про безопасность и про наш практический опыт внедрений, продолжим писать про инструменты DevSecOps. А ещё мы придумали две новых рубрики:

📍В одной мы будем рассказывать про базовые термины DevSecOps для тех, кто только начинает свой путь.

📍Во второй поделимся "грабельками", которые мы встречали, и тем, какие выводы мы сделали по итогам.

⁉️Кстати, если у вас есть вопросы, то вы всегда можете их задавать в нашем чатике!

Всем привет!

Отличная новость для пятницы. Совсем скоро, а именно, 12 ноября состоится бесплатная онлайн-конференция ADDO - All Day DevOps. Мероприятие продлится 24 часа и на нем выступят 180 спикеров из разных стран. Перечень тематических блоков и конкретных докладов можно просмотреть на сайте.

Вот примеры того, о чем будут рассказывать:
🍡DevSecOps. Our Secret Management Journey from Code to Vault
🍡DevSecOps. Automated Governance - Building a Compliant by Default Environment
🍡DevSecOps. Embedding Security in your Terraform and Cloudformation Code
🍡Cultural Transformation. Oups already Agile! DevOps Remains
🍡Modern Infrastructure. DevCovidOps - Two Sprints to Production
🍡CI/CD Continuous Everything. Get up to Speed with DevOps using Modern Development Practices
🍡DevSecOps. Kubernetes from an Attacker's Perspective

И это еще не все! Присоединяйтесь, будет интересно!

Всем привет!

По ссылке можно найти результат internship молодого специалиста в компании Appsecco (только у нас ассоциации про смесь Application Security и Prosecco? 🤔), в котором шаг за шагом решаются такие задачи как:

🍭 Создание pipeline для генерации security report для DVNA (дада, еще один damn vulnerable 😂) – использование SAST/DAST, CI/CD – Jenkins
🍭 Создание bill of materials для анализируемого приложения
🍭 «Перенос» наработок с локальной рабочей станции на AWS, отдельное внимание уделяется корректному хранению необходимых секретов
🍭 Использование полученного опыта для анализа следующего приложения – SuiteCRM

Отчет отлично структурирован, в нем есть большое количество строк кода, ссылок на статьи, наработками которых пользовался автор и даже немного верхнеуровневого сравнения open source инструментов!!!

ИТОГО: на наш взгляд это must have для любого специалиста, который хочет углубиться в практики выстраивания secured pipeline – все лаконично, просто и по делу! А вы что думаете?

P.S. Отдельно задумались над вопросом – «А почему у нас по результатам испытательного срока/internship не делают чего то подобного? Это же просто потрясающе!»

P.P.S. У ссылки на отчет не отображается preview, поэтому дублируем еще раз: https://devsecops-pipelines.ayushpriya.tech/

Друзья, коллеги и соратники по открытому коду, а также еще не примкнувшие!

3 ноября пройдет Red Hat Forum 2020 - в этот раз глобально, в едином порыве, в онлайн-формате. Если вам интересны вопросы:

❓эксплуатации контейнеров,
❓построение cloud native приложений,
❓практики DevOps
... и другие животрепещущие темы,

присоединяйтесь и узнавайте об эталонных примерах и “живых” кейсах заказчиков! В программе истории таких компаний как Росбанк, РСА, Металлоиннвест и др.

Вас ждет живое демо, а также море увлекательных тем:

📍Как оптимизировать IT-Инфраструктуру с помощью Ansible

📍Синергия средств разработки и контейнерных облачных сред

📍Как выглядит история целиком: cloud native разработка и контейнеры, CI/CD и DevOps

📍Quarkus - Java-фреймворк следующего поколения, ориентированный на Kubernetes


Встречаемся здесь: https://red.ht/Russiaforum

Привет!

Раз уж мы заговорили про еще один Damn Vulnerable, DVNA, то по ссылке можно найти «разбор» приложения с точки зрения безопасности:

🍭 Как проэксплуатировать найденные уязвимости?
🍭 Как устранить найденные уязвимости?

С примерами, строчками кода и ссылками на материалы, где более детально разбирается тот или иной способ эксплуатации/противодействия.

Вместе с отчетом, разбираемом в предыдущем посте, получится mini-лаборатория, которая позволяет идентифицировать, проверить и устранить выявленные дефекты ИБ.

В жизни все обстоит несколько иначе, но все начинается с «маленьких шагов» и рассматриваемые ресурсы как нельзя лучше подходят на эту роль ☺️

P.S. И опять не отображается preview, поэтому дублируем ссылку: https://appsecco.com/books/dvna-developers-security-guide/

Welcome to hell! Dependency hell!

В статье автор разбирает трудности, с которыми могут столкнуться python–разработчики, использующие зависимости (которых более 1,4 млн. в PyPI) и способы их решения.

Как правило, проблемы составляют не direct-зависимости (те, что вы явно указываете), а зависимости зависимостей (transitive, чтобы понять рекурсию надо сперва понять рекурсию).

На примере это может выглядеть так:

🍭 Ваше приложение использует прямую (direct) зависимость A
🍭 А, в свою очередь, использует B и C (transitive)
🍭 Для корректной работы B и C необходима зависимость D

Вроде все хорошо, в чем же проблема? Проблема может быть в том, что версии D, одновременно удовлетворяющей потребностям B и C может попросту не существовать! В итоге приложение не собирается и не работает.

Для решения этих проблем автор статьи предлагает использовать Watchman – утилиту, которая позволяет строить полный граф зависимостей и поддерживать его в актуальном состоянии для идентификации потенциальных dependency conflict.

На наш взгляд это так же крайне важно и для специалистов по ИБ, которые иногда просят разработчиков обновить зависимость на более «новую», чтобы устранить уязвимость и даже не представляют о последствиях, которые могут произойти (казалось бы, что сложного использовать n+1 версию?).

Это подводит нас к тому, о чем не говорил только ленивый – важности взаимодействия между Dev и Sec командами для поиска оптимального решения задачи ☺️

P.S. Астрологи объявили неделю неработающих preview, поэтому дублируем ссылку: https://blog.acolyer.org/2020/09/21/watchman/