Новый год в июле?!

Все мы долго ждали, и вот, наконец, это свершилось! OKD 4.5 is Generally Available!

CoreOS, операторы, developer catalog и прочие фичи из OpenShift, все как мы любим!

Без дальнейших рассуждений - бежим ставить новую версию и делиться своими впечатлениями в чате! :)

https://github.com/openshift/okd

Всем привет! Компания CyberArk, известный на российском рынке производитель PAM-решений, выпустила бесплатный продукт Secretless Broker.

По факту это прокси-сервер, который берет на себя функцию инъекции секретов в контейнеры. При этом приложению знать секрет совсем не требуется.

Как это работает:

🍭Приложение подключается к брокеру
🍭Брокер берет секрет из системы управления секретами
🍭Брокер инициирует сессию с целевой системой (например, к БД), используя секрет
🍭Брокер "соединяет" трафик между приложением и целевой системой

Брокер представляет собой sidecar контейнер, который разворачивается "рядом" с контейнером приложения.

Более детальную информацию можно получить тут.

Всем привет!

Есть свежий пост про новый функционал в Red Hat OpenShift 4.5.1!!!

С пылу с жару (еще неделя не прошла, ну почти :) ) ребята подготовили обстоятельный и подробный пост, доступный по ссылке!!!

Привет!

Если вам интересна статистика по использованию Open Source при разработке ПО, то рекомендуем обратить внимание на отчет компании Synopsys (2020 Open Source Security and Risk Analysis (OSSRA) Report).

Отчет содержит сводную информацию о таких аспектах как:

🍭 Использование Open Source в различных отраслях
🍭 Какой Open Source используют больше всего
🍭 Как часто не соблюдаются правила лицензирования Open Source
🍭 Информация о наиболее "популярных" уязвимостях в Open Source компонентах и многое другое

Скачать материал можно по ссылке :)

Вышла новая версия HashiCorp Vault 1.5!

Буквально на днях обновился этот крутой и популярный тул, который умеет secrets management, PKI и много чего ещё!!!
В новом релизе много фич, которые делают его ещё более годным для true Enterprise-внедрений.

Как вам такое?!
🍬 Нативная поддержка в Red Hat OpenShift
🍬 Поддержка HA Storage для разных бэкендов
🍬 Поддержка сертификатов VMware и NetApp ONTAP

Нам очень 👍! И это далеко не все :) Подробности можно прочитать тут: https://www.hashicorp.com/blog/vault-1-5/

Всем привет! Ещё один инструмент для аудита кластера Kubernetes с говорящим названием - kubeaudit.

Kubeaudit - это cli утилита, с помощью которой можно просканировать кластер на различные аспекты безопасности.

Например :
🍡Запуск контейнера из-под рута
🍡Наличие расширенных привилегий (capabilities)
🍡Отсутствие network policies с настройкой default-deny и пр.

Утилита поддерживает 3 режима работы:

🍡манифест - сканирование файла манифеста кластера. В этом режиме утилита также позволяет патчить конфигурацию кластера с использованием команды autofix
🍡локальный - сканирование файла конфигурации кластера (kube/config)
🍡режим кластера - сканирование всего кластера.

Более детальная информация доступна тут.

Привет! Этим теплым июльским днем хотим поделиться зимней историей, как наша команда автоматизировала ввод в строй нескольких десятков серверов у ритейлера, чтобы успеть модернизировать ЦОД к новогоднему пику продаж.

Комплекс управления конфигурациями сложился как матрешка:

☃️ Cobbler,
☃️ HashiCorp Vault,
☃️ Ansible и AWX,
☃️ и все покрыл Molecule


*Спойлер: ЦОД был вовремя модернизирован, а Дед Мороз доставил детям миллионы подарков! 🎁
https://habr.com/ru/company/jetinfosystems/blog/513132/

Всем привет!

Если вы уже успели заскучать от типовых атак на торчащие наружу облачные Docker API с последующим майнингом криптовалюты, то как раз для вас подъехала отличная статья! :)

Исследователи компании Intezer обнаружили новое вредносное ПО (это backdoor), назвав его Doki. Конечно, все в итоге сводится к вышеуказанному, но атака в совокупности с Doki реализуется действительно изящно.

Тому есть 2 причины:

Во-первых, в скомпрометированной инфраструктуре запускаются легитимные образы (это alpine с установленным curl).

Выглядит это примерно так:
🍡К Docker API создаётся запрос с указанием параметра для привязки папки контейнера к рутовой директории сервера
🍡С использованием сервиса Ngrok загружаются вредоносные файлы через curl (сетевые сканеры и "плохие бинари", среди которых и был обнаружен Doki)

Во-вторых, Doki - это такой вредонос под Linux, который не смогли выявить даже 60 антивирусов VirusTotal. К тому же он использует незадокументированный метод связи со своим оператором, используя blockchain-технологию криптовалюты Dogecoin для динамической генерации его доменных имён C2 .

Но об этом вам лучше почитать в самой статье по ссылке.

P. S. И немного про Ngrok.

Всем привет! Time to robotize!

Вы знали, что типовые рутинные процессы, выполняемые человеком в информационных системах, можно типизировать, алгоритмизировать и автоматизировать?

Для этих целей существуют специальные платформы под названием Robotic Process Automation (RPA).
Решили немного рассказать про них.

Зачем нужны RPA?
По факту есть 2 большие цели:
🍪Автоматизация простых рутинных операций или даже реализации сложных бизнес-процессов
🍪Скорость и минимизация ошибок при решении различных задач вроде почтовой рассылки или аггрегации данных из разных систем (сокращение человеческого фактора)

Почему именно RPA, а не 'классическая' автоматизация?
Есть несколько причин:
🍪Возможность использования сторонних библиотек: компьютерное зрение, OCR, встраиваемые внешние модули AI
🍪Не надо переделывать бизнес-процесс, он автоматизируется as is (роботы воспроизводят действия пользователей)
🍪Общая среда управления роботами: расписание, балансировка нагрузки, запуск разных процессов из единой точки.

Где это может быть применимо на примерах?
🍪Продажи (проверка наличия товаров на складе, письма)
🍪HR (сборка заявок в HR службу)
🍪Финансы (формирование рассылок отчётов)
🍪Внутренний контроль (аналитика по финансовой отчётности)
🍪Управление информацией (проверка контрагентов)
И это ещё не все.

Какие RPA платформы можно встретить на рынке?
🍪UIPATH (наиболее известное решение)
🍪Robin (первое решение в реестре российского ПО)
🍪Blue Prism
🍪Automation Anywhere

Если интересно, расскажем в чем разница. Пишите в чатик

Всем привет!

Сегодня скажем пару слов про харденинг и полезные инструменты для него. А так же можно ли упростить этот процесс.

Если компании не чужда автоматизация развертывания инфраструктуры, тогда относительно легко задать параметры конфигураций целевых систем.
Развернув таким образом, например, виртуальную машину, отвечающую необходимым compliance требованиям организации.

Но ведь в процессе жизненного цикла эта конфигурация может изменится!
Как понять, не произошло ли критичных с точки зрения безопасности изменений в конфигурации?
К счастью, есть решение!
Фреймворк Inspec разработанный компанией Chef, одним из лидеров в вопросах управления конфигурациями, поможет провести аудит целевых систем, не затрагивая при этом непосредственно конфигурацию. Мы не передаем и не заменяем на серверах конфигурации, но проводим проверку и получаем отчёт о конкретных изменениях в них.

Плюшки inspec:
🍩 Возможность выполнять проверки в удаленных системах посредством ssh и winrm (для Windows).
🍩 Возможность применять профили проверок из github на лету, без pull’ов.
🍩 Поддержка аудита для docker контейнеров и облачных провайдеров (AWS, Azure).
🍩 Из удаленных систем берутся только значения проверяемых параметров. Нарушить работоспособность своим сканированием нельзя.
🍩 Легко кастомизируемые профили проверок. Нет нужды проверять все параметры конфигурации систем. Проверяем только необходимое нам.
🍩 Встроенный supermarket с большим набором готовых проверок под различные системы и прикладное ПО (от Windows до Kubernetes).
Решение может быть интегрировано в конвейеры разработки, IaC системы и в целом обладает большой гибкостью применения!

Больше информации на сайте и github разработчиков.

https://inspec.io
https://github.com/inspec/inspec
Stay safe. Stay secure. 😷

Нашли картинку, которая наглядно изображает, как с помощью инструментов 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/