Изменять конфигурацию узла Kubernetes нужно не только в момент создания кластера, но и при его обновлениях или изменениях в инфраструктуре. Хорошо, если узлы можно автоматизированно пересоздать или изменить без перезагрузки узла. А что делать, если такой возможности нет или количество узлов в кластере переваливает за сотню?

Меня зовут Александр Краснов, CTO компании «Лаборатория Числитель». Мы занимаемся разработкой программного обеспечения, создаем собственные продукты в области контейнерных платформ, DevOps, облачных решений и мониторинга. Я же проектирую и внедряю Kubernetes в Enterprise.

В основе этого поста — мой доклад с DevOps Conf 2023. Я расскажу про распространенные варианты управления конфигурацией кластеров с помощью Ansible, Cluster API и OpenShif Machine Config.

Недавно в нашу компанию «Инфосистемы Джет» пришел заказчик с проблемой долгой реализации создаваемых портов на NSX-T (до 2 минут до момента запуска трафика). Основная боль заключалась в том, что новые поды K8s не всегда укладывались в timeout Health Check'a и процесс начинался опять.

Исходные данные у нас были такие. NSX использовался для построения микросегментированной сети в кластерах Kybernetes + Kyverno. Взаимодействие K8s и NSX было реализовано при помощи плагина VMware NCP. Несмотря на большое количество объектов, в интерфейсе все метрики по утилизации были в «зеленых» значениях, но ощущалось сильное замедление работы UI.

Специалисты по анализу данных используют много разных инструментов, причем новые технологии (фреймворки, библиотеки и т.д.) появляются так часто, что у начинающих свой путь в отрасли постоянно возникает вопрос, что им нужно изучать в первую очередь. Здесь вы найдете обзор базовых инструментов. В следующих постах мы продолжим тему и расскажем об инструментах, не вошедших в этот обзор.

На проектах мы часто сталкиваемся с различными интересными задачами и кейсами. Хочу поделиться одной из таких историй.

Беда пришла нежданно. Пару месяцев назад, в конце рабочего дня, когда я уже успел выключить комп и погрузился мыслями в вечерние планы, со мной связались коллеги из соседнего департамента. У их заказчика начал сбоить сервер баз данных Redis на Open Source: наблюдались дикие тормоза и потеря производительности.

Входные данные: есть три узла Redis, Standalone и две реплики, конфигурация по дефолту.

В какой-то момент Redis сильно «раздулся»: его дамп был огромен (исчислялся гигами) и на диск писался долго — показывал время запросов 2-3 секунды, не добегала репликация, видны были висящие в непонятном состоянии курсоры с тайм-аутом в час.

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

Что было дальше, описываю под катом.

Из этой статьи вы узнаете, почему важно проводить «лабораторные испытания» ML-моделей, и зачем в тестировании наработок «ученых по данным» должны участвовать эксперты из предметной области, а также — как выглядят тесты после того, как модель покинула датасайнтистскую лабораторию (и это не только мониторинг качества данных).

На первый взгляд кажется, что тестирование ML-моделей должно проходить по классическим ИТ-сценариям. Моделируем процесс, присылаем сценарии тестерам, и начинается магия — невозможные значения входных данных, попытки сломать логику системы и т. д. В некотором смысле все работает именно так: процесс разработки ML-сервисов включает и этот этап. Но только в некотором смысле — ведь у науки о данных есть масса особенностей.

Центр управления данными нашей компании занимается построением хранилищ, Data Lake, платформ данных и BI-систем. ETL — неотъемлемая часть нашей работы. Сегодня мы рассмотрим актуальные подходы к созданию подобных решений и расскажем о двух проектах, где они были реализованы нестандартными способами.

Если загуглить «работа в ИТ», то статей с заголовком «Как войти в айти» и курсов, обещающих быстрый старт в новой профессии, выпадет столько, что начнет казаться, что все вокруг только и делают, что учатся (или учат) на айтишников. ИБ-профессии дополнительно окутаны флером хакерской тематики, но в целом процесс «вкатывания» в них для человека не из индустрии от этого сильно не меняется.

Мы собрали три истории ребят, которые смогли которые работают в центре информационной безопасности: всем нашим героям около 30 лет, и до того, как перейти в новую профессию, они уже строили карьеру в других сферах, но решили всё изменить, став специалистами в сфере информационной безопасности с нуля. Чей путь был проще — решайте сами. Пост будет полезен тем, кто думает о работе в айтишной сфере, но пока сомневается (или считает, что поезд ушел вместе с перроном).

Недавно на одном из проектов для телекоммуникационной компании нам пришлось дополнительно (не без помощи коллег из ИБ J) проработать вопрос безопасного использования паролей для подключении к базе данных PostgreSQL кластера Zabbix.

Прописывать пароль для доступа к базе данных в явном виде в конфигурационном файле небезопасно. В таких случаях обычно ограничиваются возможностями разграничения прав к конфигурационным файлам Zabbix на уровне операционных систем.

Но вернемся к нашей задаче. Изучив входные данные об инфраструктуре заказчика, мы сразу обратили внимание, что коллеги в сегменте ИБ уже используют решение от HashiCorp — Vault, что и стало для нас отправной точкой:

— во-первых, Zabbix отлично интегрируется с решениями от HashiCorp;

— во-вторых, у нас есть опыт работы с HashiCorp Vault.

Основной целью было обезопасить конфигурацию HA Zabbix, убрав указываемые в явном виде логины и пароли для подключения к базе данных PostgreSQL. Сделать это нужно было так, чтобы наше решение было совместимо с уже применяемым стеком на стороне заказчика.

Итак, в этом посте пройдемся по нескольким шагам:

1. Рассмотрим нашу схему работы HA Zabbix и дадим краткую характеристику данному стеку.

2. Рассмотрим предполагаемый вариант использования Vault в связке с HA Zabbix.

3. Предложим конфигурацию для данного решения.

Привет, Хабр! В конце апреля команда CyberCamp провела митап, посвященный DevSecOps. Наше путешествие началось у острова композиционного анализа, потом мы прошли между Сциллой и Харибдой защиты контейнеров и мобильных приложений, а затем отправились исследовать другие направления DevSecOps.

В этом посте собрали полный плейлист выступлений.

На написание статьи меня сподвигли воспоминания о трудоустройстве на первую работу и сопутствующие трудности, с которыми мне пришлось столкнуться. Собеседования напоминали «день сурка» — технические специалисты бубнили, что им нужны только работники с большим конкретным опытом, а не студенты-теоретики, и им некогда заниматься «глубоким обучением». В конечном итоге мне удалось устроиться в «Инфосистемы Джет» благодаря моей хорошей подготовке к собеседованию. Чтобы облегчить жизнь будущим поколениям и дать возможность выпускникам на практике ознакомиться с доступными для студента средствами защиты информации (СЗИ), я решил написать этот пост. Рассмотрим самое базовое средство защиты компьютерной сети — межсетевой экран (МЭ.)

До событий прошлого года одной из основных платформ управления контейнерами была Red Hat OpenShift Container Platfrom. Ей пользовались компании сегмента Enterprise с высокими требованиями к функциональности и стабильности продукта, а также к уровню поддержки решения. Теперь продажи Red Hat, как и других западных решений, невозможны. Поэтому встает вопрос о выборе альтернатив.

Меня зовут Юрий Семенюков, я директор центра проектирования вычислительных комплексов «Инфосистемы Джет». С 2018 года занимаюсь развитием направления DevOps в части инфраструктуры под контейнерное окружение, руковожу проектными командами по внедрению платформ контейнеризации в Enterprise на разных дистрибутивах. В этом посте я расскажу, как крупные компании справляются с уходом западных коммерческих дистрибутивов Kubernetes.

Приветствую всех! В этой статье я бы хотел поделиться опытом подготовки и сдачи экзамена ALCSA-1.7: Сертифицированный системный администратор Astra Linux Special Edition 1.7. Вопросов от коллег (и не только) по нему было много, а информации в открытом доступе до обидного мало. Итак, пойдем по порядку.

Всем привет! Сегодня хочу рассказать о своем «семейном» проекте на Raspberry Pi. Путешествуя по миру, я постоянно сталкиваюсь с потребностью подключаться к быстрому и, что не менее важно, безопасному интернету.

Этот пост я хочу посвятить кейсу с крупного ИТ-проекта, который делала наша компания. В рамках проекта внедрялось большое количество сервисов, и для них нужно было обеспечить LDAP-аутентификацию при следующих операциях:

• Доступ в GUI-интерфейсы сервисов.

• Доступ по SSH на серверы, где функционируют сервисы, с ограничением доступа на основании членства пользователей в группах LDAP-каталога.

У заказчика уже была развернута служба каталогов Microsoft Active Directory. Требованием проекта было отсутствие прямого доступа между внедряемыми сервисами и AD. На стороне сервисов не должны были прописываться параметры сервисных учетных записей AD. Кроме того, сетевой доступ к контроллеру MS AD был разрешен только для одного хоста.

Под катом — подробности о том, как мы решили эту задачу.

Четвёртая версия ChatGPT одних заставила пищать от восторга, а других повергла в уныние. Кто-то уже нашёл этой системе множество творческих применений, а кто-то пророчит, что эта нейросеть лишит работы кучу людей. Теперь возможности ChatGPT стали ещё шире: систему интегрировали с Wolfram | Alpha, легендарным движком для вычисления ответов в самых разных областях знания. Мы перевели для вас огромную подробную статью об этом от одного из разработчиков Wolfram | Alpha.

Еще в прошлом году мы c командой решили поделиться несколькими интересными векторами получения привилегий администратора домена. По отзывам, первая статья оказалась полезной и интересной. Настало время продолжить. В этом посте я расскажу о том, как получение доступа к панели администрирования принтера может привести к компрометации всего домена Active Directory с помощью эксплуатации уязвимости PrintNightmare и использования неограниченного делегирования. А коллеги из Jet CSIRT дополнили пост рекомендациями по мониторингу на каждом этапе на случай, если вы хотите мониторить такие атаки в вашем SIEM. Краткое описание — на схеме.

Подробнее — под катом.

Привет, меня зовут Виктор Езерский, я работаю в центре управления данными «Инфосистемы Джет». Мы занимаемся построением хранилищ, Data Lake, платформ данных, ETL/EL-T и BI-систем. Последние 5–7 лет при построении хранилищ данных у наших заказчиков одна из часто встречаемых архитектур — Data Vault. Мы участвовали в доработке готовых хранилищ на базе Data Vault и делали Data Vault «с нуля».

Из опыта борьбы я вынес одно правило: Data Vault без фреймворка и автоматической генерации — большая беда. В этом посте расскажу, почему, а также поделюсь нашими подходами к созданию генератора. Сразу предупреждаю, что не дам готовых рецептов, но расскажу о наших основных подходах и что они нам дали.

Привет. Меня зовут Александр Родченков, я занимаюсь речевыми технологиями в компании «Инфосистемы Джет». Как-то я задался вопросом — когда люди стали пытаться синтезировать или распознавать речь? Изучив вопрос, раскопал много криповых любопытных историй и решил с вами поделиться.

Привет, Хабр! В конце февраля команда CyberCamp провела митап, посвященный сетевой безопасности. На митапе разобрали, что не так с сетями и как этим пользуются хакеры, что можно использовать для защиты — от фреймворков до технологий — и как обеспечить баланс между безопасностью сети и удобством для бизнеса.

В этом посте собрали полный плейлист выступлений:

● Колосс на глиняных ногах, или Почему сети несовершенны и как этим пользуются злоумышленники / Сергей Павленко, руководитель департамента проектирования и внедрения центра информационной безопасности, «Инфосистемы Джет»

● Про пентест: сетевые атаки, которые никто не согласует / Евгений Артемьев, специалист по тестированию на проникновение, «Инфосистемы Джет»

● От плоских сетей к нулевому доверию. Безопасная сетевая архитектура: концепции и фреймворки / Станислав Калабин, руководитель группы сетевой безопасности, «Инфосистемы Джет»

● Профит анализа сетевого трафика для SOC / Алексей Леднев, руководитель отдела обнаружения атак экспертного центра безопасности, Positive Technologies (PT ESC)

● Проблема передачи пароля при веб-аутентификации / Александр Жердев, вирусный аналитик, Group-IB

● Как правильно выстроить защиту от DDoS-атак для своей Enterprise-сети с множеством публичных сервисов / Глеб Хохлов, директор по продукту, MITIGATOR

Чтобы посмотреть эти выступления, крути вниз.