Сергей Наумов, senior-backend разработчик отдела информационной безопасности Авито объясняет, почему Kubernetes Secrets недостаточно для крупной инфраструктуры и как автоматизировать управление сертификатами в enterprise-среде.

Истечение TLS-сертификата в крупной инфраструктуре может остановить критичный сервис: пользовательский сценарий перестает работать не из-за ошибки бизнес-логики, а из-за того, что инфраструктура потеряла доверие к собственному соединению. На масштабе сотен и тысяч сервисов ручная модель PKI перестает быть управляемой: центральная команда становится bottleneck, а риск просроченных сертификатов растет вместе с количеством внутренних платформ, баз данных, API и Kubernetes-кластеров.

В Авито Сергей Наумов участвовал в переходе от централизованного ручного управления сертификатами к сервисной модели PKI. Цель проекта — автоматизировать выпуск и обновление примерно 95% внутренних TLS-сертификатов, включая в контур автоматизации около 2000 сертификатов ключевых платформ: PaaS, DBaaS и вычислительных платформ для аналитики и ML-нагрузок.

В рамках проекта Сергей проектировал архитектуру интеграции Kubernetes-среды с внутренним CA на базе step-ca. Решение было задумано не как еще один cluster-level контроллер по модели cert-manager, а как более гибкий механизм, который может работать через entrypoint-wrapper, init container или sidecar и встраиваться в разные Kubernetes-кластеры без жесткой зависимости от конкретной реализации платформы. Такой подход был важен для большой компании с органическим ростом инфраструктуры: кластеры развиваются по-разному, а схема выпуска сертификатов должна оставаться понятной и поддерживаемой для владельцев платформ и сервисных команд.

Сергей, почему тема Kubernetes Secrets стала такой заметной именно сейчас?

Kubernetes давно стал стандартом для запуска сервисов, но возможности штатного механизма Secrets часто воспринимают шире, чем то, для чего он на самом деле предназначен. Kubernetes Secret — это удобный объект для доставки чувствительных данных в workload, но не полноценная система управления жизненным циклом секрета.

По умолчанию значения Kubernetes Secrets кодируются в base64 и сохраняются в etcd без шифрования на уровне Kubernetes API. Base64 — это формат представления данных, а не защита. Если у пользователя, workload или инфраструктурного компонента есть права на чтение Secret-объекта, он получает значение в форме, которую легко декодировать. Если encryption at rest не включен, прямой доступ к etcd также становится критичным риском.

В небольшом кластере это может долго не приводить к видимым проблемам. В enterprise-среде, где есть сотни команд, тысячи сервисов и разные поколения платформенных решений, риск быстро растет. Секреты начинают жить дольше, чем должны; один service account используется в нескольких местах; инфраструктурные компоненты получают доступ "про запас"; а ротация токенов и сертификатов остается ручной или полуручной.

Проблема не в том, что Kubernetes Secrets нельзя использовать в production. Их можно использовать как часть архитектуры, если включены encryption at rest, RBAC по принципу least privilege, ограничения по namespace и контроль доступа к pod. Проблема в другом: Kubernetes Secrets сами по себе не дают централизованный аудит, lease-модель, автоматическую ротацию внешних credentials, управляемый отзыв и единые политики выдачи для разных платформ.

В отчете Wiz по IngressNightmare фигурировала оценка около 43% уязвимых облачных сред. Что важно понимать в этой цифре?

Эта цифра относится не ко всем Kubernetes-проблемам вообще, а к конкретному исследованию Wiz по цепочке уязвимостей ingress-nginx, получившей название IngressNightmare. По оценке Wiz, около 43% облачных сред были уязвимы к этой цепочке, а более 6500 кластеров публично экспонировали vulnerable admission controllers.

Кейс важен не только сам по себе, а как пример архитектурного риска. CVE-2025-1974 получила оценку 9.8/10 по шкале CVSS (Common Vulnerability Scoring System — международный стандарт оценки критичности уязвимостей), что соответствует максимально критичному уровню угрозы. При определенных условиях атакующему не нужны Kubernetes credentials — достаточно сетевого доступа к pod network или admission controller ingress-nginx. Дальше уязвимость позволяла выполнить код в контексте pod ingress-controller.

И здесь проявляется ключевая проблема: слабым местом становится не сам Secret-объект, а компонент, которому выдали слишком широкие права. В стандартной установке ingress-nginx мог иметь доступ к Secrets на уровне всего кластера, потому что ему нужно работать с TLS-секретами для Ingress. Если такой компонент скомпрометирован, атака быстро превращается в доступ к секретам across namespaces и потенциальный takeover кластера.

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

Какие ошибки в работе с паролями, токенами и ключами доступа вы чаще всего видите в Kubernetes-средах?

Обычно повторяются три сценария.

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

Второй — переиспользование одной учетной записи или одного набора прав для нескольких сервисов. Разработчик берет готовый шаблон, копирует service account и использует его в разных workloads. В результате компрометация одного сервиса автоматически увеличивает blast radius и открывает доступ к соседним системам.

Третий — отсутствие автоматической ротации. Долгоживущие внешние ключи, статические токены и сертификаты без контролируемого продления могут оставаться действующими месяцами или годами. Даже если современные Kubernetes-механизмы уже поддерживают более короткоживущие service account tokens, старые интеграции и внешние credentials продолжают создавать долг безопасности.

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

Почему централизованная модель управления сертификатами перестает работать в крупной инфраструктуре?

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

Проблемы начинаются, когда количество сервисов растет до сотен и тысяч. Каждая новая база данных, внутренний API, сервис в Kubernetes или платформа для ML требует собственных TLS-сертификатов. Центральная команда физически перестает успевать сопровождать весь этот объем вручную.

Возникает bottleneck: продуктовые команды ждут выпуска сертификатов, инфраструктурная команда работает в режиме постоянного реагирования, а ошибки из-за человеческого фактора становятся вопросом времени. Истечение одного сертификата может остановить критичный сервис. Если речь идет о PaaS, DBaaS или внутренних платформах для вычислений, последствия быстро переходят из технической зоны в бизнес-риски: недоступность сервисов, сбои пользовательских сценариев, прямые финансовые потери.

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

Какое решение вы проектировали для Kubernetes?

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

Я предложил другой подход: вынести логику получения и обновления сертификатов ближе к workload и сделать ее понятной для сервисных команд. В зависимости от сценария это может быть entrypoint-wrapper, init container или sidecar. Такой компонент аутентифицирует workload, обращается к внутреннему CA на базе step-ca, получает сертификат с нужными параметрами и обеспечивает обновление без ручного участия инженера.

Это не замена cert-manager во всех сценариях. cert-manager хорошо подходит, когда сертификат должен управляться как Kubernetes-ресурс и сохраняться в Kubernetes Secret. Но для нашей задачи было важно не привязывать всю модель к единому Kubernetes-контроллеру и не требовать одинаковой зрелости от всех кластеров. Нам нужна была схема, которую можно внедрять постепенно, в разных платформах, с разными ограничениями и понятной моделью ответственности: Kubernetes-платформа предоставляет среду исполнения, а lifecycle сертификата остается частью сервисной модели PKI.

Отдельная часть работы была связана с step-ca. Open-source step-ca уже поддерживает автоматизированную выдачу и продление X.509-сертификатов, ACME и разные provisioners. Но для большой компании важна более гибкая модель политик: разные платформы требуют разных правил выдачи, сроков жизни, шаблонов сертификатов, ограничений по SAN и способов авторизации запроса. Поэтому в архитектуре нужно было заложить доработки и интеграционные механизмы, которые позволяют управлять политиками в разрезе платформ и сценариев.

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

Как в этой архитектуре работает Vault и почему одного Kubernetes Secrets недостаточно?

Vault в такой архитектуре становится control plane для доступа к секретам и учетным данным. Часть данных может храниться как static KV, а для баз данных, облачных ключей и сервисных учетных данных можно использовать dynamic secrets с TTL, lease и отзывом. Это важное отличие от модели, где приложение получает постоянный пароль и хранит его в конфигурации годами.

Для dynamic secrets и service tokens Vault выдает lease с ограниченным сроком жизни. Клиент должен либо продлить доступ, либо получить новый credential. Если lease отозван, секрет перестает быть валидным и не может продлеваться дальше. Это сокращает окно риска при утечке и дает нормальный audit trail: кто, когда и к какому секрету обращался.

Но важно не упрощать: внешний secret manager сам по себе не гарантирует, что секреты исчезнут из etcd. Если использовать External Secrets по модели синхронизации в Kubernetes Secret, копия все равно окажется в etcd, и ее нужно защищать encryption at rest и RBAC. Снизить зависимость от etcd можно только при правильном способе доставки: например, через runtime injection, Vault Agent, CSI-driver или другой механизм, который не оставляет долгоживущую копию секрета внутри Kubernetes API.

Фактически задача меняется: мы перестаем просто хранить секреты и начинаем управлять доступом к ним как отдельным инфраструктурным процессом. Для enterprise это принципиально: важен не только сам секрет, но и то, кто его получил, на какой срок, по какой политике, как он ротируется и как ограничивается blast radius при компрометации.

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

Главная цель проекта — автоматизировать выпуск и обновление примерно 95% TLS-сертификатов, используемых во внутренней инфраструктуре. Речь идет примерно о 2000 сертификатах для ключевых платформ: PaaS, DBaaS, платформ вычислений для анализа данных и нейросетевых нагрузок.

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

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

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

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

По каким метрикам можно понять, что система управления секретами и сертификатами действительно работает эффективно?

Я бы смотрел не на сам факт наличия Vault, step-ca или PKI-платформы, а на операционные показатели.

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

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

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

Четвертая — audit trail. Нужно понимать, кто, когда и по какой политике получил сертификат или секрет. Без этого невозможно нормально расследовать инциденты и доказывать корректность модели доступа.

Пятая — управляемость blast radius. Один сервис не должен иметь возможность открыть доступ ко всей инфраструктуре. Если компрометация одного компонента ограничивается его зоной ответственности, значит архитектура работает в правильном направлении.

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

Что бы вы посоветовали командам, которые только начинают строить Kubernetes-инфраструктуру?

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

Второе — не считать Kubernetes Secrets полноценной системой secret management. Это базовый механизм Kubernetes, который нужно дополнять encryption at rest, RBAC, аудитом, ротацией и, для enterprise-сценариев, внешним secret manager или PKI-платформой.

Третье — соблюдать least privilege с самого начала. Один сервис не должен видеть секреты другого, а инфраструктурные компоненты не должны получать доступ "про запас". Все временные исключения в правах почти всегда становятся постоянными.

Четвертое — выбирать архитектуру с учетом ownership. Технически можно поставить еще один контроллер в кластер, но в большой компании важнее вопрос: кто будет владеть этой логикой, кто будет поддерживать политики, кто будет объяснять модель сервисным командам и как решение будет жить в разных поколениях платформ.

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