Корпоративное ядро: как оно устроено

Сразу важно оговориться: корпоративное ядро и КИИ-контуры – это разные среды с разными задачами. В технологических сегментах КИИ требования строже, а фокус смещен в сторону изоляции и максимального импортозамещения. Корпоративная среда, о которой мы и говорим, проще по функционалу и ориентирована на поддержку пользователей и управленческих процессов.

В зависимости от зрелости архитектуры и глубины легаси корпоративный сегмент может быть как жестко отделен от КИИ-контуров, так и существовать с ними в управляемой гибридной модели. В обоих случаях именно требования КИИ задают архитектурные рамки, в которых проектируется корпоративная среда

В корпоративном сегменте энергетики ядро состоит из набора базовых сервисов: каталог, почта, коммуникации, документооборот, файловый слой, рабочие места и защита. Его фундамент – доменная структура, часто на Alt Domain или RedADM (службы на базе Samba DC): эти решения без сюрпризов проходят проверки совместимости и корректно работают с Kerberos и LDAP.

В реальных проектах переход к новому домену почти всегда начинается с гибридного режима. Старый Active Directory продолжает хранить SID и привязки приложений – без trust-связей массовую миграцию просто не запустить. Так домен становится точкой опоры для всех остальных компонентов. Почта – один из первых сервисов в корпоративном сегменте, который начинает жить по доменной модели: учетные записи, группы, права. И чаще всего именно она на прикладном уровне первой замечает любые отклонения в каталоге.

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

Документооборот и файловый сервис – отдельный слой. Для пользователя это привычные папки с доступом к документам, но под капотом здесь ролевая модель, оргструктура и строгие ACL. Когда включается централизованная модель прав, самодельные сетевые диски исчезают из контура, а файловый слой превращается в управляемую систему доступа.

На уровне ниже находится невидимый пласт сервисов, на которых держится все ядро: DNS/DHCP домена, репликация, политики и настройки безопасности. Ошибки в любом из них могут спровоцировать каскад проблем – от задержек авторизации до потери доступа у части пользователей. На такие сценарии и заточены внутренние ППИ/ПМИ каждого компонента. Сценарии отрабатывают вручную, фиксируют протоколы, закрывают замечания – и только после этого переходят к пилоту.

Все это – «серверная» часть ядра. Но самый сложный участок начинается там, где архитектура сталкивается с пользователями – на АРМ (рабочих станциях). Здесь требуется подключение к каталогу, перенос профилей, миграция данных, проверка приложений, контроль целостности и унификация конфигураций.

В корпоративном сегменте на практике применяются переходные схемы – гибридный режим домена и поэтапная миграция пользовательских сервисов. В КИИ-контуре такие компромиссы возможны далеко не всегда

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

В рамках такой стандартизации на пользовательском уровне и появляется частичный dual-OS: критичные приложения остаются в Windows, а пользовательская среда переезжает в Linux. Это самый безопасный способ пройти миграцию без остановки процессов.

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

Как выглядит внедрение на практике

На проектах внедрение почти всегда проходит в три этапа.

1. Прототипирование – создание в миниатюре будущей инфраструктуры и выявление несовместимостей.
2. Настройка паттернов – сборка образов, настройка групп, OU, профилей, fallback-логики.
3. Переходный период – введение dual-OS, выравнивание политик и подготовка к ОПЭ.

Прототипирование занимает от трех до шести месяцев. На этом этапе всплывает все, что невозможно увидеть на этапе проектирования. Где-то рабочие станции не загружаются на новых образах без обновления BIOS. Где-то плоттеры, сканеры и терминалы требуют ручной настройки. Профили Windows при переносе в Linux теряют ярлыки, MIME-ассоциации и политики. Если корпоративный домен в гибридном режиме, любое расхождение по времени, сбой Kerberos или конфликт GPO могут вывести из строя авторизацию на половине контура.

После пилота начинается настройка паттернов – определяем, какие драйверы исключать из образа, как собирать профили, какие группы синхронизировать, какие параметры ядра уменьшают количество сбоев, как организовать корректный fallback.

Но часть задач паттернами не решить – слишком много рабочих мест держится на Windows-приложениях. Поэтому dual-OS закрепляется как рабочая норма в корпоративном контуре: пользовательский профиль — в Linux, технологические приложения — в Windows, а архитектура постепенно приводится к единому набору политик, профилей и прав.

Откат в этом контуре обязателен. Пользователь должен иметь возможность вернуться в привычную среду в любой момент. На практике команда стремится уложиться в 10–15 минут – иначе миграционный участок становится неуправляемым

Даже после перехода в ОПЭ двухслойная конфигурация сохраняется. Часть сервисов – на новой платформе, часть – на старой. Пока среды существуют параллельно, они должны быть синхронны. Расхождение в правах, политиках или репликации моментально ломает согласованность контуров – и превращается в локальный инцидент.

Информационная безопасность как каркас архитектуры

Эта архитектура не может существовать без четкой рамки ИБ. Причем ИБ здесь – не надстройка, а несущая конструкция. Она определяет, что допустимо в контуре, а что нет, и где проходят реальные границы риска.

Виртуализацию разрешают только там, где можно контролировать изоляцию гостевых систем. Каналы управления – только внутри защищенных сегментов. Требования к виртуализации опираются на ГОСТ 56938: разделение зон исполнения, защита потоков управления, никаких «черных ящиков» в обновлениях.

Внешние сетевые зависимости исключаются, если они не описаны в проекте и не находятся под контролем заказчика. Неконтролируемые каналы передачи данных запрещены. Поэтому к Kerberos, репликации и маршрутам авторизации относятся как к минному полю: любая двусмысленность – это уже риск.

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

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

И все это не имело бы смысла без гарантированного восстановления: система должна уметь возвращать себя в рабочее состояние через резервные копии, откат и проверенные сценарии. Например, компания в финсекторе после отказа всей инфраструктуры, потери ЦОД должна заработать через 2 часа.

Стандартизация через эксплуатацию

Когда среду удается стабилизировать на первой площадке, возникает главный вопрос: можно ли повторить тот же результат без пересборки с нуля? В энергетике – можно.

Конечно же, у компаний в разных регионах – своя история, парк оборудования или глубина легаси. Но архитектурные требования одинаковые везде. Они и формируют единый «слепок» корпоративного ядра при сохранении изоляции КИИ-контуров: правила для каталога, почты, коммуникаций и подготовки рабочих мест.

Если система стабильно прошла ОПЭ на одной площадке, она, как правило, так же ведет себя и на других

В этот момент внедрение перестает быть разовым проектом и превращается в последовательный сценарий. Архитектуру не приходится пересобирать – запускается отлаженная цепочка шагов с заранее понятными точками риска и стабильности. А полевые практики – унифицированные образы, dual-OS, fallback-механизмы – закрепляются как формальные требования.

Импортонезависимое ядро – основа цифровой устойчивости

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

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

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

Рассмотрим, что представляет собой MFA и как помогает избежать утечек.

Проблемы с паролями и принципы MFA

Несмотря на развитые технологии, простые пароли остаются уязвимыми. Фишинг обманывает пользователей через фальшивые сайты или имейлы, brute-force использует автоматизированный перебор комбинаций, а утечки происходят при взломе внешних сервисов, где пароли повторяются.

MFA противостоит этому, требуя не менее двух факторов аутентификации. Основные типы:

• То, что известно пользователю: пароль или PIN-код — наиболее распространенный, но и самый слабый фактор.
• То, что есть у пользователя: устройство вроде смартфона, USB-токена или аппаратного ключа.
• То, кем выступает пользователь: биометрия типа отпечатка пальца, распознавание лица или сканирование сетчатки.

От двухфакторной аутентификации (2FA) MFA отличается гибкостью: 2FA обычно ограничивается паролем плюс одноразовым кодом (например, из SMS), в то время как MFA позволяет добавлять третий фактор для критических систем.

С MFA часто интегрируют связанные технологии. Единый вход (SSO) упрощает доступ: пользователь авторизуется один раз и получает права на несколько сервисов. Модель нулевого доверия (Zero Trust) проверяет каждый запрос заново, учитывает IP, время и устройство, независимо от источника. Вместе они создают многоуровневую защиту, идеальную для распределенных команд.

Общие принципы работы MFA-систем

MFA-системы обычно развертываются как облачные сервисы (SaaS) или on-premise решения, с акцентом на совместимость с существующими инфраструктурами. Они поддерживают протоколы вроде RADIUS, LDAP, SAML и OpenID Connect/OAuth, что позволяет интегрировать их с VPN, VDI, RDP, SSH, межсетевыми экранами (например, Check Point, Cisco, UserGate), облачными платформами (VMware, Huawei Cloud) и приложениями (G Suite, Salesforce).

При выборе MFA стоит обратить внимание на:

• Методы доставки факторов: SMS/звонки, push-уведомления в мобильных приложениях, боты в мессенджерах (например, Telegram), OTP-токены (аппаратные или программные), U2F/FIDO-ключи и биометрия. Разнообразие методов повышает удобство и адаптивность.
• Политики доступа: Возможность задавать правила на основе IP, времени суток, дней недели или групп пользователей. Это помогает ограничить доступ, например, только из офисной сети или в рабочее время.
• Инфраструктура и надежность: Размещение в сертифицированных дата-центрах с защитой от DDoS, высоким уровнем доступности (SLA не ниже 99.9%) и резервированием данных.
• Интеграция и развертывание: Минимальные требования к аппаратным ресурсам (например, 4 ядра CPU и 4 ГБ RAM для агентов), открытый код для прозрачности и быстрая настройка (от нескольких часов).
• Аудит и мониторинг: Журналы событий с фиксацией IP, страны, результатов аутентификации и алертами на подозрительную активность.
• Самообслуживание: Порталы, где пользователи самостоятельно настраивают факторы или сбрасывают пароли.
• API для кастомизации: Для встраивания MFA в собственные приложения, с поддержкой регистрации пользователей и генерации токенов.

Важно учитывать конфиденциальность: системы должны маскировать чувствительные данные в уведомлениях и соответствовать регуляциям, по типу GDPR или российским законам о защите ПДн.

MULTIFACTOR как пример MFA-решения

В качестве практического примера можно рассмотреть российскую систему MULTIFACTOR, которая применяется для защиты удалённых подключений — RDP, VPN, VDI и SSH.

Решение разворачивается в гибридной модели: часть компонентов работает в облаке, часть устанавливается у заказчика. Облачная часть расположена в российских дата-центрах (Selectel, LinxCloud), сертифицированных по стандартам PCI DSS и ISO 27001. В инфраструктуру встроена защита от DDoS-атак, SLA по доступности заявлен на уровне 99,99%, состояние сервисов можно отслеживать на публичной статус-странице.

Что требуется со стороны клиента:

• служба каталогов (Active Directory или аналог);
• RADIUS-адаптер для обработки запросов;
• портал самообслуживания для пользователей.

Адаптер проверяет первый фактор (логин/пароль) локально, а второй передаёт в облако. Для работы необходима базовая конфигурация (4 ядра CPU, 4 ГБ RAM на Windows Server), а портал самообслуживания требует ещё меньше ресурсов. Ключевые компоненты системы доступны в открытом коде.

Интеграция занимает от нескольких часов: установка агентов и настройка по документации. Поддерживаются стандартные протоколы RADIUS, LDAP, SAML, OpenID Connect/OAuth, что позволяет встроить решение в большинство инфраструктур — файрволы (Check Point, Cisco, UserGate), облачные платформы (VMware, Huawei Cloud), VDI (Citrix, VMware Horizon), RDP/SSH, а также в приложения вроде G Suite, Salesforce и Slack.

Совместимость охватывает Windows (включая Outlook Web Access, Remote Desktop Gateway), Linux (SSH, PAM-модули, sudo), а также российские дистрибутивы (ALT Linux, Astra Linux, РЕД ОС). MULTIFACTOR внесён в реестр отечественного ПО, имеет лицензию ФСТЭК и может использоваться в проектах импортозамещения.

Методы аутентификации:

• мобильное приложение (iOS/Android) с push-уведомлениями и QR-регистрацией;
• Telegram-бот;
• SMS и телефонные звонки;
• OTP-токены (аппаратные и программные, включая Rutoken и ЯКлюч);
• U2F/FIDO-ключи;
• биометрия (Face ID, отпечаток пальца) — при этом приватные ключи остаются на устройстве.

Политики доступа можно задавать так: по IP-диапазону, времени суток, дню недели или группам пользователей. Внедрён единый вход (SSO), портал самообслуживания для настройки 2FA и сброса паролей, а также журнал событий с алертами на подозрительные попытки входа.

Для разработчиков предусмотрен REST API — регистрация пользователей, вызовы на аутентификацию, интеграция MFA в сторонние продукты. Это позволяет адаптировать систему под SaaS-сценарии и корпоративные приложения.

Кейс MULTIFACTOR демонстрирует, как можно построить MFA с поддержкой разных факторов, протоколов и сценариев использования в российском контексте. Перед внедрением важно протестировать совместимость с инфраструктурой и оценить удобство для сотрудников — от этого зависит реальная эффективность защиты.

Рекомендации по выбору и внедрению MFA

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

MFA — не панацея, но в сочетании с Zero Trust и SSO значительно повышает устойчивость к атакам. Выбирайте системы с гибкими политиками и открытой документацией, чтобы минимизировать зависимость от вендора и облегчить масштабирование.

Загибайте пальцы:

1. Собрать Docker-образ.
2. Обновить конфигурацию в Kubernetes.
3. Применить изменения командами kubectl.
4. Проверить, что все работает.
5. Если не работает — откатить изменения, исправить, повторить.

И так каждый раз. А если на проекте не только тестовая среда, но и предпродакш, продакшн? А если команда из 10 разработчиков? Кошмар!

Инструмент Argo CD ускоряет развертывание приложений, синхронизирует Git-репозиторий с фактическим состоянием в кластере. В итоге у разработчика больше времени на написание кода и меньше проблем с деплоем. Компания тоже выигрывает — получает более быстрые и надежные релизы.

После прочтения статьи вы сможете самостоятельно настроить деплой Kubernetes с помощью ArgoCD и применить эти знания в собственных проектах.

ArgoCD раскрывается лучше, когда уже понятен весь путь до GitOps: контейнеры, CI/CD, Kubernetes, Helm, наблюдаемость и безопасность. Общий контекст собран в статье Roadmap DevOps-инженера в 2026 году, а сам подход отдельно разобран в материале что такое GitOps простыми словами.

Введение в ArgoCD: возможности и преимущества

Git коммитишь — кластер обновляется

Вася написал новую фичу и отправил ее в Git. Через 2 минуты функция уже работает в тестовой среде, но с багом. Вася исправляет код, делает коммит, — и через 2 минуты исправление снова в тестовой среде.

Когда все готово к релизу, девопс применяет изменения в ветке, и ArgoCD автоматически обновляет продакшн.

Без ArgoCD: 30+ минут ручной работы на каждый деплой, высокая вероятность ошибки.

С ArgoCD: 2 минуты автоматической работы, минимальный риск ошибок.

Изменили код, отправили в Git — работа сделана. Платформа GitOps без вашего участия обнаружит изменения и обновит приложение в кластере.

Интерактивная панель управления

В Argo CD видно все компоненты приложения — деплойменты, сервисы, конфигмапы — и их состояние. В один клик можно посмотреть историю синхронизаций, детали развертывания и логи.

ArgoCD — это быстрый доступ к событиям, управление средами и кластерами с одной панели, мгновенный откат к предыдущей версии. Также доступна проверка изменений перед их применением.

Универсальный подход к конфигурациям

Команда применяет Helm для управления зависимостями?

— ArgoCD интегрируется с ним напрямую.

Предпочитаете Kustomize для настройки под разные среды?

— ArgoCD распознает эти конфигурации автоматически.

Используете стандартные YAML-манифесты?

— Они тоже поддерживаются без дополнительной настройки.

Безопасный доступ для команды любого размера

Можно разделить доступ между участниками проекта с точностью до отдельных приложений и действий:

• Девопсы управляют всеми развертываниями.
• Разработчики получают права на просмотр логов и статуса своих сервисов.
• Тестировщики видят статус только тестовых сред.

Права разграничиваются по проектам, именам и типам ресурсов. Например, команда фронтенда видит только свои сервисы, бэкенд-разработчики — только свои.

Система интегрируется с корпоративными провайдерами аутентификации через OIDC, LDAP, SAML. Каждый сотрудник сможет использовать персональные учетные данные для входа.

Установка и настройка Argo CD

ArgoCD устанавливается в действующий кластер Kubernetes с помощью стандартного набора манифестов. Перед установкой потребуются: настроенный kubectl, файл kubeconfig и работающий CoreDNS.

Команды создают пространство имен argocd и устанавливают компоненты: серверы приложений, репозиториев и другие службы.

Доступ к ArgoCD осуществляется через CLI и веб-интерфейс.

CLI устанавливается из официальных релизов:

• brew install argocd — для macOS, Linux и WSL.
• бинарный файл — для Windows.

По умолчанию сервер ArgoCD не имеет внешнего IP. Это значит, что веб-интерфейс и API ArgoCD доступны только из кластера Kubernetes.

Есть три способа настройки доступа:

1. Изменение типа сервиса на LoadBalancer:

2. Настройка Ingress-ресурс для маршрутизации трафика через входной контроллер кластера.

3. Использование kubectl port-forward для временного доступа:

Начальный пароль администратора генерируется автоматически и хранится в секрете argocd-initial-admin-secret:

Вход в систему через CLI:

После первого входа необходимо сменить пароль:

Секрет argocd-initial-admin-secret следует удалить после смены пароля, так как он содержит пароль в открытом виде:

Для веб-интерфейса используется тот же адрес и учетные данные, что и для CLI.

Регистрация кластера (необходима только для внешних кластеров):

При добавлении внешнего кластера ArgoCD создает сервисный аккаунт argocd-manager в пространстве имен kube-system и выдает ему права администратора. При работе с тем же кластером, где установлен Argo CD, используется адрес https://kubernetes.default.svc.

Создание приложения:

То же самое через веб-интерфейс:

1. Нажать кнопку «New App».
2. Заполнить форму с указанием имени, Git-репозитория, пути к манифестам.
3. Выбрать целевой кластер и пространство имен.
4. Нажать «Create».

После создания приложение находится в состоянии «OutOfSync». Для развертывания ресурсов в кластер:

Через CLI:

Через веб-интерфейс:

1. Нажать «Sync» для нужного приложения.
2. В открывшейся панели выбрать «Synchronize».

Для автоматической синхронизации при изменениях в Git-репозитории используется флаг –sync-policy automatic:

При загрузке манифестов из репозитория Арго автоматически определяет формат и применяет соответствующий инструмент для развертывания.

Основные команды и работа с CLI

Рассмотрим 4 базовые команды:

• Добавление нового приложения.
• Проверка состояния развертывания.
• Автоматическая и ручная синхронизация.
• Откат изменений.

Добавление нового приложения

Команда argocd app create создает приложение в Argo CD, связывая Git-репозиторий с целевым кластером Kubernetes.

Нужно указать имя приложения, источник манифестов и целевую среду:

Альтернативой ручному созданию приложения служит определение через YAML-файл:

Проверка состояния развертывания

Команда argocd app get отображает текущее состояние приложения, включая статус синхронизации, ревизию Git и состояние ресурсов:

Для вывода информации о ресурсах приложения используется флаг -o wide:

Можно отслеживать состояние ресурсов во время синхронизации:

Еще ArgoCD сохраняет историю синхронизаций приложения:

Автоматическая и ручная синхронизация

Команда argocd app sync применяет изменения, обнаруженные в Git-репозитории, к кластеру Kubernetes:

При ручной синхронизации Argo CD:

1. Скачивает манифесты из Git.
2. Формирует план изменений.
3. Применяет его к кластеру.
4. Отслеживает состояние до завершения развертывания.

Синхронизация определенной ревизии Git:

Принудительная синхронизация:

Обновление только определенных ресурсов:

Откат изменений

Команда argocd app rollback отменяет последнюю синхронизацию и возвращает приложение к предыдущему стабильному состоянию:

По умолчанию откат выполняется на предыдущую успешную ревизию. Для отката к конкретной ревизии требуется указать ее ID:

где 5 — номер ревизии из истории.

При откате не происходит изменений в Git-репозитории — это временное изменение, направленное на быстрое восстановление работоспособности.

После отката приложение перейдет в состояние «OutOfSync», поскольку Git-репозиторий по-прежнему содержит новую версию.

Для долгосрочного решения после отката нужно:

1. Исправить ошибки в манифестах.
2. Отправить исправления в Git.
3. Синхронизировать приложение.

Работа с ArgoCD в реальных проектах

ArgoCD дополняет классические CI/CD-системы, разделяя ответственность за процесс доставки. CI-системы отвечают за сборку кода и создание артефактов, ArgoCD берет на себя развертывание в Kubernetes.

В GitHub Actions пайплайн компилирует приложение, собирает Docker-образ, обновляет манифест с новым тегом образа и отправляет изменения в Git. ArgoCD замечает изменения в репозитории и обновляет приложение в кластере.

Подробнее про интеграцию CI/CD с GitHub Actions

GitLab CI/CD использует подобную схему — сначала тестирование и сборка, затем запись актуальных версий в манифесты. CI-пайплайн завершается, как только изменения попадают в Git. Остальную работу делает ArgoCD.

Подробнее про инструменты CI/CD на практике от DevOps-инженеров

Jenkins требует дополнительной настройки для интеграции с ArgoCD. Возможна работа через REST API ArgoCD или через обновление манифестов в Git-репозитории. Для командной строки Argo CD создают отдельные сервисные аккаунты с ограниченными правами.

Настройка уведомлений

Уведомления Argo CD информируют команду о состоянии приложений. Система уведомлений настраивается в ConfigMap argocd-notifications-cm:

• Для Slack нужно определять шаблоны сообщений и триггеры событий. Соединение настраивается через токен бота. Приложения активируют уведомления через аннотации.
• Microsoft Teams работает через веб-хуки. Каждый канал получает собственный URL-адрес, который ArgoCD использует для отправки сообщений.
• Email-оповещения требуют настройки SMTP-сервера. ArgoCD поддерживает TLS-шифрование и аутентификацию. Письма содержат детальную информацию о событиях и могут включать ссылки для быстрого доступа.

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

Управление секретами

Стандартная модель GitOps требует хранения всех манифестов в Git, что небезопасно.

Популярные решения для управления секретами:

• Sealed Secrets. Публичный ключ используется для шифрования секретов перед сохранением в Git. Контроллер в кластере расшифровывает их закрытым ключом и создает стандартные Secret-объекты.
• HashiCorp Vault. Манифесты содержат переменные, которые заполняются значениями из Vault в момент синхронизации. Секреты никогда не попадают в Git-репозиторий.

3 лучшие практики использования ArgoCD

1. Организация репозитория

Структура Git-репозитория влияет на эффективность работы с Argo CD. Рассмотрим два основных подхода: «моно» и «мульти» модель.

• Монорепозиторий хранит все манифесты в одном месте. Каталоги первого уровня разделяют приложения и конфигурацию среды. Преимущество — целостная структура и возможность внесения согласованных изменений.
• Мультирепозиторная модель разделяет компоненты по нескольким репозиториям. Каждая команда управляет своим набором приложений. Конфигурации для разных окружений хранятся отдельно. Этот подход четко разграничивает ответственность.

App of Apps упрощает управление множеством приложений через главное приложение ArgoCD. Один манифест верхнего уровня содержит определения для всех приложений, что упрощает развертывание однотипной инфраструктуры.

2. Использование Kustomize и Helm

Kustomize накладывает патчи на базовые манифесты. Конфигурация определяет основные параметры приложения, оверлеи содержат изменения для конкретных сред.

Helm применяет шаблонизацию для создания манифестов. Чарты содержат шаблоны с переменными, значения которых задаются в файлах values.yaml. Для каждого окружения создается собственный файл значений.

Можно комбинировать оба инструмента. Helm создает базовые манифесты, а Kustomize настраивает их под конкретные требования.

3. Мониторинг приложений и настройка alert-уведомлений

Арго собирает метрики синхронизации, состояния здоровья, времени развертывания. Данные передаются в Prometheus для создания дашбордов в Grafana и настройки алертов.

Система уведомлений информирует команды о критичных изменениях: ошибках синхронизации, деградации здоровья, успешных развертываниях. Алерты отправляются в Slack, Teams, Email через настраиваемые триггеры и шаблоны.

6 популярных ошибок при работе с ArgoCD

Ошибка аутентификации по SSH-ключу. ArgoCD выдает «Permission denied (publickey)» при попытке доступа к репозиторию. Причина — неправильно настроенный или отсутствующий SSH-ключ.

Решение:

• Проверить корректность SSH-ключа.
• Убедиться, что в репозитории ключ добавлен как deploy key с правами чтения.
• Проверить формат ключа (должен начинаться с —–BEGIN OPENSSH PRIVATE KEY—–).

Отсутствие прав доступа к репозиторию. Даже при корректных учетных данных пользователь может не иметь прав чтения.

Решение:

• Проверить права доступа пользователя или deploy key к репозиторию.
• Убедиться, что для организации не включено SSO или 2-FA.

Несоответствие версий Helm. Argo CD использует встроенную версию Helm, которая может отличаться от локальной.

Решение:

• Проверить версию Helm в Argo CD через argocd admin helm version.
• Настроить кастомную версию Helm через конфигурацию argocd-cm.

Отсутствующие значения в values.yaml. Ошибка «Error: execution error at line X» с указанием на неопределенное значение.

Решение:

• Убедиться, что все required значения указаны в файле values или через флаги –set
• Использовать условные блоки для необязательных параметров

Одна из основных проблем в GitOps-модели — расхождение между фактическим состоянием кластера и описанием в Git.

Отказ при синхронизации из-за drifts. ArgoCD отображает ресурс как «OutOfSync» и отказывается выполнять синхронизацию.

Решение:

• Использовать флаг –force при синхронизации для перезаписи изменений.
• Включить опцию автоматического самовосстановления (self-heal) для критичных ресурсов

Ошибка Update не разрешена для некоторых полей. Kubernetes запрещает изменение определенных полей после создания ресурса.

Решение:

• Добавить аннотацию argocd.argoproj.io/sync-options: Replace=true

Подведем итоги

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

В мире, где все постоянно ломается, Argo CD — тот самый друг, который поможет собрать приложение, пока вы пьете кофе и притворяетесь, что все так и задумано.

Если после внедрения ArgoCD у вас внезапно появилось свободное время — не пугайтесь, это нормально. Используйте его, чтобы наконец-то прочитать те 348 вкладок про Kubernetes, которые вы открыли 2 года назад. А еще можете использовать его, чтобы почитать наш тг-канал, найдете больше советов!

MultiDirectory, разработанная компанией МУЛЬТИФАКТОР — российская служба каталогов с открытым кодом, в которой используется тот же набор атрибутов, что и в AD — это упрощает интеграцию с различными системами. Она поддерживает Kerberos, LDAP, SSO, двухфакторную аутентификацию и легко интегрируется с текущей IT-инфраструктурой. В статье расскажем:

• чем служба каталогов MultiDirectory отличается от AD и других систем;
• как она помогает управлять доступами и безопасностью в корпоративной сети;
• какие функции упрощают администрирование и защиту данных.

Что такое службы каталогов и как они работают

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

Сотрудник входит в систему — служба каталогов проверяет его логин и пароль. Для этого используются протоколы аутентификации, такие как LDAP или Kerberos. MultiDirectory поддерживает Kerberos, поэтому пользователям не нужно вводить пароли повторно: система автоматически подтверждает их личность.

Вся эта информация хранится в иерархической или реляционной структуре, которая организована по объектам: пользователи, группы, устройства и так далее. Когда администратор меняет пароль пользователя в службе каталогов, это затрагивает все системы, которые используют каталог для аутентификации через LDAP или Kerberos, но при этом изменения в сами системы не вносятся. Пользователь также может самостоятельно сменить пароль через программу, в которой он работает, а она сама отправит запрос в каталог и обновит данные через протокол LDAP или Kerberos.

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

Какие есть службы каталогов

Вот наиболее популярные решения:

• Microsoft Active Directory. Он интегрируется с Windows Server и поддерживает протокол LDAP и механизм доменов.
• OpenLDAP. Он используется в UNIX- и Linux-системах, подходит для опенсорсных систем. Но это только реализация LDAP — у него нет встроенного Kerberos, DNS, DHCP и так далее.
• Apache Directory. Java-реализация службы каталогов, поддерживающая LDAP и другие протоколы, часто используется в кроссплатформенных средах.

Зарубежные Open-Source-решения не поддерживаются официально либо требуют значительных затрат на локальную интеграцию и поддержку — это создаёт дополнительные риски для бизнеса.

В моменте, когда компании ищут замену Active Directory, они сталкиваются с проблемами:

• Не все решения поддерживают 2FA для Kerberos и совместимы с текущей инфраструктурой.
• Сложный перенос учётных записей пользователей.
• Не хватает встроенной двухфакторной аутентификации.

MultiDirectory имитирует работу AD, поэтому системы, в которых раньше была AD, можно перенастроить на MultiDirectory без изменений в работе — они будут думать, что всё так же работают с AD.

Основные технические характеристики MultiDirectory

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

Опенсорсный исходный код MultiDirectory написан на Python — это дает возможность гибкой настройки и контроля на отсутствие закладок. Код можно бесплатно использовать и предлагать исправления. Развёртывание происходит через Docker, что упрощает установку: система запускается на любом сервере с поддержкой контейнеров, без сложных зависимостей и долгой настройки.

Более того, в отличие от обычных служб каталогов, MultiDirectory хранит данные в базе Postgres. Поэтому репликация и бэкапирование настраиваются через саму СУБД или внешние инструменты, а не самой службой каталогов.

Функциональные возможности и простая миграция

MultiDirectory позволяет плавно «переехать» с Active Directory, а еще в ней есть поддержка 2FA, SSO и централизованное управление учетными записями. Рассказываем об этих функциях ниже.

Централизованное управление учётными записями

Администраторы могут управлять учётными записями пользователей и правами через открытый API или вручную с помощью понятного веб-интерфейса. Также у них есть возможность создавать, изменять и удалять учётки и разграничивать права пользователей.

Доступ пользователей настраивается через группы и роли:

• Domain Admins — администраторы с полными правами
• Read Only — пользователи, которые могут только просматривать данные
• Domain Users — пользователи, у которых есть доступ только к своим учетным записям

Надежность, безопасность и 2FA

Хэши паролей хранятся в базе данных. А если нужно дополнительное шифрование, можно воспользоваться наложенными средствами защиты или встроенными функциями PostgreSQL. Для аутентификации используется Kerberos — протокол, реализация которого не предполагает передачу пароля по каналам связи. Это обеспечивает гораздо более высокий уровень безопасности по сравнению с тем же NTLM.

Двухфакторная аутентификация в MultiDirectory работает для нескольких интерфейсов: Admin API, LDAP и Kerberos. Каждый из них может быть защищен с помощью 2FA, а правила его использования настраиваются через политики безопасности.

1. Admin API (HTTP) поддерживает OTP или Push-уведомления.
2. LDAP также работает с OTP или Push.
3. Kerberos поддерживает только Push.

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

2FA снижает риск компрометации аккаунтов, даже если основной пароль утёк.

MULTIFACTOR — 2FA-система того же разработчика — интегрирована с MultiDirectory, поэтому настройка двухфакторной аутентификации не требует установки дополнительных адаптеров.

Режим Bypass

Если облачный сервис MULTIFACTOR временно недоступен, в MultiDirectory автоматически включается режим Bypass. В зависимости от настроек можно разрешить или запретить вход в систему без 2FA.

Настройки режима позволяют:

• Разрешить вход без 2FA в случае сбоя, чтобы бизнес-процессы не останавливались.
• Полностью запретить авторизацию при отсутствии двухфакторной проверки — если безопасность важнее доступности.

Поддержка DNS

MultiDirectory интегрируется с Bind9 и позволяет управлять всеми типами записей зоны через веб-интерфейс. При настройке DNS автоматически создаются необходимые записи для Kerberos и LDAP.

Быстрая авторизация с Single Sign-On (SSO)

Технология единого входа (SSO) позволяет пользователям вводить пароль только один раз — дальше система автоматически авторизует их в корпоративной почте, CRM, облачных сервисах и других внутренних приложениях.

В чем плюсы:

• Сотрудники не тратят время на постоянный ввод паролей.
• IT-отделу не приходится восстанавливать доступ к забытым учетным записям.
• Снижается риск утечек паролей.

Заключение

MultiDirectory — это российская альтернатива AD с поддержкой 2FA, SSO и централизованного управления.

Задачи, которые решает MultiDirectory:

• централизованное управление учетными записями, компьютерами группами;
• единая точка идентификации, аутентификации и авторизации;
• поддержка современных стандартов безопасности;
• управление DNS-записями через Bind9
• гибкая интеграция с внешними системами.

Продукт уже работает в корпоративных средах, а в 2025 году разработчики планируют регистрацию в реестре отечественного ПО и выпуск Enterprise-версии с расширенными возможностями. В ней появятся:

• поддержка доверия доменов;
• дополнительные методы защиты;
• DHCP-сервер;
• гранулированная настройка доступа;
• делегирование полномочий;
• интерфейс для логов;
• журнал событий;
• и многое другое.

Почему LDAP?

Зачем использовать LDAP, когда для OpenShift доступны другие варианты: HTPasswd, Basic Auth, Github, Keystone? LDAP — это протокол открытого стандарта, известный своей лёгкостью, безопасностью и зрелостью, но все ещё развивающийся. Обычно он используется для обмена информацией о пользователях, системе, сети и услугах.  Представьте его как дерево каталогов, в котором вы можно искать сверху вниз и между самими каталогами. Также мы LDAP можно использовать в инфраструктуре, как единую точку для управления доступами к ресурсам.

Далее будем отталкиваться от того, что в инфраструктуре уже есть LDAP.

Добавим отдельную группу openshift и пользователя srv_acct_ocp. С помощью ldapsearch проверим есть ли связь между LDAP и master нодой OpenShift cluster — например, с помощью команды ниже. Она создаёт связь с сервером LDAP с использованием предоставленного bindDN (флаг -D) и пароля (флаг -W):

Если все параметры верны, будет возвращен вывод LDIF, содержащий информацию на сервере.

Добавление провайдера LDAP в Openshift

В Openshift 4 есть хорошая инструкция для добавления LDAP провайдера.Но я опишу всё в рамках статьи — для наглядности. Все действия выполняются с ноды master.

• Для начала создадим project:

• Добавим secret для нашего LDAP: 

• После того, как мы создали secret, нужно создать ConfgiMap, который будет содержать информацию о сертификате ca.crt:  

• На последнем этапе создаём custom resource (CR), который будет содержать информацию о параметрах  нашего identity provider:

• Применяем только что созданный CR:

• Проверим корректно ли работает наш добавленный провайдер, войдем в cluster с помощью пользователя LDAP srv_acc_okd:

Управление доступами

Отлично, мы добавили провайдера LDAP. Теперь нам необходимо управлять привилегиями в нашем Openshift cluster. В инструкции к Openshift нам предлагают создать sync LDAP, но он запускается руками — это нам не подходит. Поэтому отойдём от родной инструкции и добавим решение на базе автоматизации — создадим cronjob, ещё одну сущность в нашем Openshift cluster. По сути это обычный cron:

• Создаём project для нашего cronjob:

• Создаём новый cronjob — ldap-group-sync.yaml :

Заключение

В данной статье мы удачно добавили провайдера LDAP  в наш Openshift cluster и настроили автоматическую синхронизацию групп и пользователей с нашим LDAP.