В релиз-кандидате Argo CD 3.5 разработчики закрыли сразу три болезненные темы для крупных GitOps-инсталляций: добавили внутренний mTLS между компонентами, проверку подписей Git-коммитов и нативный интерфейс для ApplicationSet. Для команд, у которых безопасность Argo CD давно упиралась в «доверяем внутренней сети» и ручную проверку YAML, это не косметика, а пересборка базовой модели доверия.
Об этом сообщает InfoQ. Речь идет о версии-кандидате, выпущенной в июне 2026 года: до финального релиза еще возможны правки, но набор нововведений уже хорошо показывает, куда проект двигает GitOps-платформу для enterprise-сценариев. И если раньше Argo CD часто хвалили за удобство эксплуатации, а ругали за отдельные пробелы в цепочке поставки и наблюдаемости, то в 3.5 команда явно взялась именно за эти старые долги.
Главное изменение для security-команд и платформенных инженеров связано с repo-server. До этого трафик между ним и остальными внутренними компонентами, включая API-сервер и контроллеры, оставался без шифрования. На практике это означало неприятный перекос: на входе организации нередко поднимали mTLS, а вот внутри самого Argo CD часть критичного обмена жила в модели «кластеру можно верить». В 3.5 repo-server начинает требовать клиентские сертификаты от подключающихся компонентов. Если кастомных сертификатов нет, он может сам создавать самоподписанные сертификаты в памяти, без опоры на файловую систему. Для продакшена это выглядит не как модный чекбокс, а как устранение довольно неловкой исторической дыры: внутренние health-checks и служебные вызовы тоже попадают под более внятную защиту.
Вторая история не менее практичная: Source Integrity. Теперь оператор может требовать, чтобы Git-источники имели валидные подписи перед синхронизацией. Включается это либо через спецификацию приложения с параметром sourceIntegrity.required: true, либо через CLI-команду argocd app set --source-integrity-required. Для тех, кто строит процессы вокруг GitOps, смысл предельно земной: если репозиторий или чей-то доступ к нему скомпрометирован, Argo CD хотя бы не будет молча раскатывать неподписанные или подмененные манифесты. Это не серебряная пуля против supply chain-атак, но очень нужная базовая проверка, которой в продукте явно не хватало.
Третий headline-функционал выглядит менее драматично, но для повседневной работы может оказаться самым заметным: ApplicationSet получил нативное управление в UI. Раньше эти ресурсы хорошо решали масштабирование, когда один шаблон порождает множество приложений, но операторам приходилось идти в YAML или kubectl, чтобы понять, что именно будет создано. Теперь в интерфейсе появились представления списка, фильтрации и деталей, а также вкладка Preview Apps, показывающая будущие приложения до деплоя. Функцию делали инженеры из Intuit, Red Hat, GoTo и Octopus Deploy, что само по себе неплохо показывает спрос со стороны команд, которые уже живут в крупных GitOps-контурах. Для платформенных команд это минус еще один повод объяснять разработчикам, почему «посмотреть в UI нельзя, надо читать шаблон».
Что меняется для платформенных команд
Помимо трех центральных анонсов, Argo CD 3.5 переводит из alpha в beta две важные возможности. Первая — impersonation. Система теперь может выполнять серверные операции от имени конкретного пользователя: это касается потоковой передачи логов, удаления ресурсов и синхронизации. Если настроить impersonation через AppProject или RBAC-политику, механизм автоматически применяется ко всем серверным операциям. Для мультиарендных кластеров это вопрос не красоты, а аудита: становится проще понять, кто именно инициировал чувствительное действие, а не разбираться с обезличенным «это сделал Argo CD». Вторая — Source Hydrator. Функция разделяет «сухие» манифесты и уже гидрированный результат, а в beta-версии позволяет задавать разные значения drySource.repoURL и syncSource.repoURL. Проще говоря, шаблоны и отрендеренные манифесты можно держать в разных репозиториях с разными правами доступа. Для зрелых GitOps-практик это уже не экзотика, а вполне рабочий паттерн.
Есть и набор менее громких, но полезных изменений. Argo CD 3.5 добавляет поддержку Helm 4, сохраняя обратную совместимость с Helm 3. ApplicationSet теперь можно разворачивать в любом namespace, а не только в namespace самого Argo CD; по данным InfoQ, это закрывает давний запрос команд, которые хотят управлять GitOps по пространствам имен, а не через единую централизованную точку. Появились и ограничения по concurrency для ApplicationSet, чтобы контролировать число приложений, обрабатываемых одновременно, и не положить ни кластер, ни внешние Git API собственной автоматизацией. Для Azure AD предусмотрен обход проблемы с переполнением group claims через Microsoft Graph API, а для Azure DevOps-репозиториев добавили аутентификацию через Service Principal вместо зависимости от PAT. Эти детали не делают заголовок, но именно на них обычно держится спокойный вечер дежурного инженера.
На фоне конкурентов
Интересно, что три главные функции релиза очень по-разному выглядят на фоне конкурентов — и это хорошо подсвечивает архитектурные компромиссы GitOps-инструментов. Flux, в версии 2.8 от марта 2026 года, вообще не сталкивается с тем же классом проблемы внутреннего mTLS: его контроллеры общаются через объекты Kubernetes API, а не через прямой gRPC-трафик, так что отдельного внутреннего канала, который срочно надо закрывать, там просто нет. При этом проверка подписей коммитов у Flux появилась раньше через GPG в GitRepository API, так что здесь Argo CD скорее догоняет. С UI ситуация обратная: Flux 2.8 получил web dashboard через отдельный Flux Operator и показывает Kustomization и HelmRelease, но аналога Preview Apps для шаблонной генерации там нет.
У Rancher Fleet другая архитектура: вместо gRPC используется агентская модель на websocket, поэтому потребность во внутреннем mTLS решается иначе, на уровне ingress и доверия к агентам. Зато встроенного механизма Source Integrity у Fleet нет: чтобы требовать подписанные коммиты, команде придется опираться на политику Git-провайдера или admission webhook. Jenkins X идет еще по другой траектории и делает ставку на пайплайны Tekton, включая Tekton Chains и GPG-подписанные релизы. Это усиливает контроль цепочки поставки, но уже на уровне CI/CD-конвейера, а не непосредственно GitOps-контроллера. Иными словами, Argo CD 3.5 не изобретает новый класс защиты, а закрывает те места, где его архитектура особенно просила доработок.
Для русскоязычной аудитории, особенно для тех, кто строит внутренние платформы, вывод довольно приземленный. Безопасность Argo CD перестает быть разговором только про внешний ingress, секреты и RBAC. Начиная с 3.5, проект заметно серьезнее относится к внутренним каналам связи, к происхождению манифестов и к прозрачности массовых операций через ApplicationSet. Если команда уже использует Argo CD в мультикомандной или регулируемой среде, этот релиз-кандидат выглядит как повод пересмотреть базовые настройки, а не просто обновить образ в кластере. Следующий логичный вопрос теперь не в том, нужны ли GitOps-инструментам функции supply chain security, а в том, насколько быстро рынок перестанет считать их опциональными.