Безопасность реестра образов: стратегии защиты от уязвимостей в 2026 году | AdminWiki
Logo

Безопасность реестра образов: стратегии защиты от уязвимостей в 2026 году

02 августа 2026 8 мин. чтения
Содержание статьи

Почему безопасность реестра образов критична в 2026 году

В 2026 году атаки на цепочки поставок программного обеспечения выросли на 42% по сравнению с предыдущим годом. Реестр контейнерных образов - центральная точка отказа в инфраструктуре. Компрометация реестра дает злоумышленнику контроль над всеми развертываниями в кластере Kubernetes. Один вредоносный образ способен скомпрометировать сотни микросервисов за считанные минуты.

Уязвимость CVE-2026-67290 в FreeRDP до версии 3.29.0 - пример того, как ошибка heap out-of-bounds read в декодере TSMF FFmpeg открывает вектор для выполнения кода. Эта CVE не связана напрямую с реестром, но демонстрирует каскадный эффект: образ с уязвимой библиотекой попадает в реестр, затем в продакшен, и атакующий получает точку входа в кластер. Стандарты CIS Benchmarks и NIST SP 800-190 требуют обязательного контроля содержимого реестра и разграничения доступа. Игнорирование этих требований ведет к штрафам при аудите и прямым финансовым потерям от инцидентов.

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

Перед внедрением конкретных мер проведите аудит текущего состояния безопасности. Используйте готовый чек-лист аудита Docker и Kubernetes для выявления слабых мест за один день. Дальше разберем каждый слой защиты: от сканирования уязвимостей до проверки подлинности образов в кластере.

Автоматическое сканирование уязвимостей: интеграция Trivy и Clair

Сканирование уязвимостей - базовая гигиена реестра. Trivy и Clair решают эту задачу с разными подходами. Trivy работает как standalone-сканер без базы данных, анализируя образы по загруженным CVE-словарям. Clair использует собственную базу и API для непрерывного мониторинга образов в реестре. Выбор зависит от архитектуры: Trivy лучше встраивается в CI/CD, Clair - в постоянный мониторинг реестра.

Установка и настройка Trivy в пайплайне CI/CD

Trivy устанавливается одной командой и сразу готов к работе. Для GitLab CI добавьте этап в .gitlab-ci.yml:

container_scanning:
  stage: security
  image: aquasec/trivy:latest
  script:
    - trivy image --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  allow_failure: false

Флаг --exit-code 1 блокирует пайплайн при обнаружении HIGH или CRITICAL уязвимостей. JSON-отчет сохраняется артефактом для аудита. Для GitHub Actions конфигурация аналогична:

- name: Scan image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'registry.example.com/app:latest'
    format: 'json'
    output: 'trivy-report.json'
    severity: 'CRITICAL,HIGH'

Настройте порог допустимых уязвимостей в зависимости от контекста. Для dev-сборок допустим уровень MEDIUM с пометкой unfixed. Для production - только CRITICAL и HIGH с обязательным исправлением. Trivy поддерживает сканирование файловых систем, git-репозиториев и конфигураций Kubernetes, что закрывает смежные векторы атак.

Интеграция Clair с Docker Registry

Clair разворачивается как отдельный сервис и подключается к Docker Registry через механизм уведомлений. Архитектура: Registry отправляет webhook при push образа, Clair загружает слои, анализирует их и сохраняет результаты в PostgreSQL. Запрос отчетов идет через REST API:

GET /v1/layers/{layer_id}?features&vulnerabilities

Настройка webhook в конфигурации Registry:

notifications:
  endpoints:
    - name: clair
      url: http://clair:6060/notifications
      timeout: 500ms
      threshold: 5
      backoff: 1s

Clair требует отдельной базы данных и периодического обновления CVE-фидов. В production-среде настройте мониторинг доступности Clair - его падение создает слепую зону в безопасности реестра. Harbor объединяет оба подхода: встроенный Trivy для сканирования по требованию и фоновый анализ через Clair-совместимый API.

Детальную настройку безопасности контейнеров с конкретными командами и чек-листом смотрите в руководстве по безопасности Docker-контейнеров.

Управление доступом: настройка RBAC для реестра контейнеров

RBAC в реестре ограничивает, кто может пушить, пуллить и удалять образы. Базовая модель Harbor включает три уровня: проекты, роли и пользователи. Проект - изолированное пространство для группы образов. Роль определяет набор разрешений внутри проекта. Пользователь или сервисный аккаунт получает роль в конкретном проекте.

Создание ролей и проектов в Harbor

Создайте три проекта для разделения сред:

# Через API Harbor
curl -X POST "https://registry.example.com/api/v2.0/projects" \
  -H "Authorization: Basic $TOKEN" \
  -d '{"project_name":"production","public":false}'

curl -X POST "https://registry.example.com/api/v2.0/projects" \
  -H "Authorization: Basic $TOKEN" \
  -d '{"project_name":"staging","public":false}'

curl -X POST "https://registry.example.com/api/v2.0/projects" \
  -H "Authorization: Basic $TOKEN" \
  -d '{"project_name":"development","public":true}'

Роли в Harbor: Limited Guest (только pull), Guest (pull и просмотр), Developer (push, pull, сканирование), Master (управление образами), Project Admin (полный контроль проекта). Для CI/CD создайте сервисного робота с минимальными правами:

curl -X POST "https://registry.example.com/api/v2.0/projects/production/robots" \
  -d '{"name":"gitlab-runner","access":[{"resource":"repository","action":"push"}]}'

Робот получает токен, который используется в пайплайне. Никогда не используйте учетные записи сотрудников для CI/CD - компрометация токена разработчика с правами администратора реестра приведет к полной потере контроля.

Интеграция RBAC с корпоративным каталогом (LDAP/Active Directory)

Harbor поддерживает LDAP/AD для централизованной аутентификации. Настройка в harbor.yml:

ldap:
  url: ldaps://ldap.company.com
  search_dn: cn=admin,dc=company,dc=com
  search_password: admin_password
  base_dn: dc=company,dc=com
  filter: (objectClass=person)
  uid: sAMAccountName
  scope: subtree

После подключения каталога группы AD маппятся на роли Harbor. Группа "k8s-admins" получает роль Project Admin в production, "developers" - Developer в development. При увольнении сотрудника доступ блокируется автоматически через AD, без ручной очистки учетных записей в реестре. Проверьте маппинг командой:

curl -X POST "https://registry.example.com/api/v2.0/ldap/users/search" \
  -d '{"username":"employee_login"}'

Шифрование данных: защита при передаче и хранении

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

Настройка TLS для Harbor с помощью Let's Encrypt

Harbor использует Nginx как reverse proxy. Сертификаты Let's Encrypt выпускаются через certbot и автоматически обновляются. Установка и настройка:

certbot certonly --standalone -d registry.example.com

# В harbor.yml укажите пути к сертификатам
https:
  port: 443
  certificate: /etc/letsencrypt/live/registry.example.com/fullchain.pem
  private_key: /etc/letsencrypt/live/registry.example.com/privkey.pem

Автоматическое обновление сертификатов настраивается через cron. Добавьте в crontab задачу, которая обновляет сертификат и перезагружает Harbor:

0 3 * * * certbot renew --quiet --post-hook "docker compose -f /opt/harbor/docker-compose.yml restart nginx"

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

# /etc/containerd/certs.d/registry.example.com/hosts.toml
server = "https://registry.example.com"
[host."https://registry.example.com"]
  capabilities = ["pull", "resolve"]
  ca = "/etc/ssl/certs/registry-ca.crt"

Шифрование хранилища образов

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

cryptsetup luksFormat /dev/sdb1
cryptsetup luksAddKey /dev/sdb1 /root/registry-keyfile
cryptsetup luksOpen /dev/sdb1 registry_encrypted
mkfs.ext4 /dev/mapper/registry_encrypted
mount /dev/mapper/registry_encrypted /data/registry

Для облачных хранилищ используйте server-side encryption S3. Harbor поддерживает S3-совместимые бэкенды с автоматическим шифрованием объектов. Ротация ключей выполняется на стороне провайдера без изменения конфигурации реестра. Timeweb Cloud предоставляет облачные хранилища с встроенным шифрованием и поддержкой S3 API для бэкенда реестра.

Проверка подлинности образов и политики допуска в Kubernetes

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

Подписание образов с помощью cosign

Cosign - инструмент из экосистемы Sigstore для подписания и верификации контейнерных образов. Генерация ключевой пары:

cosign generate-key-pair
# Создаются cosign.key (закрытый) и cosign.pub (открытый)

Подписание образа после сборки:

cosign sign --key cosign.key registry.example.com/production/app:v1.2.3

Подпись сохраняется в реестре рядом с образом. Закрытый ключ храните в KMS (AWS KMS, HashiCorp Vault, Azure Key Vault). Cosign поддерживает keyless-подписание через OIDC, где ключ генерируется эфемерно, а подпись верифицируется через прозрачный журнал. Для CI/CD это безопаснее постоянных ключей - скомпрометированный токен пайплайна не даст доступ к закрытому ключу.

Создание политики OPA Gatekeeper для проверки сигнатур

Gatekeeper проверяет наличие подписи у каждого образа при создании пода. ConstraintTemplate для верификации:

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequireimagesignature
spec:
  crd:
    spec:
      names:
        kind: K8sRequireImageSignature
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequireimagesignature
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not startswith(container.image, "registry.example.com/production")
          msg := sprintf("Image %v is not from trusted registry", [container.image])
        }

Kyverno - альтернатива Gatekeeper с более простым синтаксисом политик. Пример политики Kyverno, запрещающей образы без подписи:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-signature
      match:
        resources:
          kinds:
            - Pod
      verifyImages:
        - imageReferences:
            - "registry.example.com/production/*"
          key: |-
            -----BEGIN PUBLIC KEY-----
            ...
            -----END PUBLIC KEY-----

Политика действует на уровне admission controller и блокирует создание пода до проверки подписи. Это последний рубеж защиты: даже если образ попал в реестр в обход сканирования, Kubernetes не запустит его без валидной подписи.

Комплексная стратегия защиты: объединяем все меры

Защита реестра выстраивается эшелонированно. Каждый слой закрывает определенный вектор атаки и компенсирует возможные отказы предыдущего:

  1. CI/CD пайплайн: Trivy сканирует образ на этапе сборки, блокирует при критических CVE, cosign подписывает чистый образ.
  2. Реестр: Harbor проверяет RBAC, пускает только авторизованных пользователей, Clair фоново перепроверяет образы на новые уязвимости.
  3. Kubernetes: Gatekeeper/Kyverno верифицирует подпись, Network Policies изолируют поды, runtime security мониторит аномалии.

Мониторинг реестра настраивается через встроенные метрики Harbor в Prometheus. Критические алерты: рост количества критических уязвимостей, попытки пуша с невалидной подписью, аномальная активность pull из production-проекта. Логи Harbor отправляются в SIEM для корреляции с событиями из Kubernetes и CI/CD.

План реагирования на инцидент компрометации реестра:

  • Немедленная блокировка скомпрометированной учетной записи через API Harbor.
  • Удаление вредоносного образа из всех проектов.
  • Проверка всех запущенных подов на наличие образа с подозрительным digest.
  • Ротация всех секретов, к которым имел доступ скомпрометированный пользователь.
  • Анализ логов аудита Harbor для определения масштаба инцидента.

Для комплексного внедрения DevSecOps с моделью ответственности и планом на 90 дней используйте практический справочник по интеграции безопасности в DevOps. Автоматизация всех проверок через комплексный аудит безопасности IT-инфраструктуры закроет слепые зоны между реестром, кластером и сетью.

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

Поделиться:
Сохранить гайд? В закладки браузера