Настройка безопасности Harbor: сканирование, подписи и RBAC

Задача: безопасный реестр вместо дорогих платформ

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

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

Типовые риски выглядят буднично, но бьют больно: вредоносные или уязвимые образы, которые попали в сборку по цепочке; утечки, когда приватные образы скачивают без нужных прав; случайные удаления тегов или проектов, после которых нечего деплоить; подмена образа под знакомым тегом (например, "latest"), которую никто не замечает.

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

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

Основные понятия Harbor на простом языке

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

Что вы видите в интерфейсе Harbor

Проще всего думать так:

• Проект - отдельная папка для команды или продукта. Многие правила задаются именно внутри проекта.
• Репозиторий - место внутри проекта для образов одного приложения (например, backend).
• Артефакт - конкретная сборка (обычно контейнерный образ), которую можно скачивать и проверять.
• Тег - понятное имя версии (v1.4.2, release-2026-01, latest). Важно помнить, что тег можно перезаписать.
• Robot-аккаунт - технический пользователь для CI/CD, чтобы автоматизация могла пушить и пулить образы без личных логинов.

Права доступа и уровни настроек

В Harbor есть роли на уровне проекта (например, Project Admin, Maintainer, Developer, Guest) и системный администратор, который управляет установкой целиком. Хорошая практика - давать людям минимум прав, а для CI использовать robot-аккаунты с доступом только к нужным проектам.

Часть политик включается на уровне системы (общие параметры, интеграции, базовые ограничения), а часть - на уровне проекта (кто имеет доступ, нужно ли сканирование, правила хранения, доверие к образам).

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

Сканирование образов: что проверять и когда запускать

Сканирование образов - это проверка того, что внутри контейнера нет известных уязвимостей. Обычно сканер анализирует пакеты ОС (библиотеки, утилиты) и зависимости языков (npm, pip, Maven и т.д.), а затем сравнивает версии с базой CVE. Уровни критичности (Low, Medium, High, Critical) помогают быстро оценить риск. Critical часто означает, что есть известный способ эксплуатации и последствия могут быть серьезными.

Чтобы сканирование реально помогало, заранее решите, когда оно запускается. Чаще всего используют три режима: при каждом push (максимум контроля, но больше нагрузка), по расписанию (например, ночью, чтобы перепроверять старые образы после обновления базы), и вручную (для разового аудита).

Отчет сканера лучше читать не как список страшных слов, а как подсказку к решению: блокировать выпуск или разрешить. Практичный подход - запретить деплой образов с Critical и High, а для Medium оставить окно на исправление, если сервис не выходит наружу и есть компенсирующие меры. В Harbor это обычно оформляют политиками проекта, чтобы правила работали одинаково для всех.

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

Чтобы не перегрузить систему, начните с компромисса: сканируйте только новые теги при push, а полный пересмотр запускайте ночью. Тогда очевидные проблемы ловятся сразу, а плановый скан поднимает новые CVE по старым образам и дает время исправиться до следующего релиза.

Подписи и доверие к образам: простой процесс без магии

Подпись образа отвечает на простой вопрос: кто это собрал и можно ли этому верить. Она защищает от подмены по пути от сборки до запуска. Даже если кто-то получит доступ к реестру или перезапишет тег, проверка подписи покажет, что образ не тот.

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

Базовый процесс выглядит так:

• Создайте ключи для подписи и определите, где они хранятся (не в репозитории и не в общих чатах).
• Включите в Harbor проверку подписей для нужных проектов.
• Опишите правило: какие репозитории и теги требуют подпись (например, только release/prod).
• Настройте CI так, чтобы он подписывал образ сразу после сборки и перед публикацией.
• Запретите развертывание неподписанных образов на стороне кластера или пайплайна деплоя.

Заранее продумайте смену ключей. Минимальный план - держать два ключа на период перехода (старый и новый), чтобы не остановить релизы. Если есть подозрение на компрометацию, действуйте жестче: отзовите доверие к ключу, перевыпустите ключи, пересоберите критичные образы и включите проверку только по новому ключу.

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

• Доверенные образы - только те, что подписаны релиз-аккаунтом CI.
• Теги для продакшена принимаются только из одного проекта Harbor.
• Любой образ без подписи считается тестовым, даже если тег выглядит как latest.

Так подписи становятся не криптомагией, а обычным контролем качества.

RBAC: как раздать права и не потерять контроль

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

На практике роли часто раскладывают так: администратор проекта управляет участниками и политиками; разработчик пушит и тянет образы, но не меняет правила безопасности; гость чаще всего только тянет (pull). Отдельно стоят robot-аккаунты: доступ для CI/CD и автоматизаций, чтобы не использовать личные логины.

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

• Pull (чтение): для рантайма, тестов и команд, которые только запускают.
• Push (загрузка): для сборки и публикации из CI.
• Удаление артефактов: только для ответственных и лучше по процессу.
• Управление политиками (сканирование, подписи, правила хранения): только для админов проекта.
• Управление участниками: ограничьте 1-2 людям, чтобы права не расползались.

Самый надежный способ не запутаться - разделять доступ по проектам. Например, отдельные проекты для prod, test и песочницы. Тогда разработчик может свободно экспериментировать в sandbox, но в prod имеет только push/pull, без удаления и без прав менять политики.

Опасные действия лучше резать заранее: запретите удаление и изменение политик всем, кроме владельца проекта. Подрядчикам давайте отдельный проект или группу с правом только pull. Если подрядчику нужен push, выдайте robot-аккаунт с ограничением по проекту и сроком действия, а не роль админа.

Пример: CI пушит образы в test (robot-аккаунт с правом push только в test). После проверки релиза ответственный переносит или публикует тот же образ в prod, где у большинства участников только pull.

Пошаговая настройка: безопасный минимум за один проход

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

Сначала определите структуру: несколько проектов под команды и среды. Например, отдельные проекты для продуктов и отдельно prod и non-prod. Так проще держать порядок и раздавать права.

Дальше включите сканирование образов контейнеров и задайте пороги. Практичный минимум: сканировать при push и перед деплоем, а в production блокировать образы с критическими (Critical) уязвимостями. Для теста можно начать мягче (например, предупреждения), но заранее зафиксируйте, когда предупреждения превращаются в блокировку.

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

Параллельно настройте RBAC через сервисные учетные записи. Для CI используйте robot-аккаунты: один робот на проект или даже на конкретный пайплайн. Дайте им только push/pull в свой проект, без прав админа и без доступа к чужим репозиториям.

Чтобы разбираться не после инцидента, включите аудит и заведите привычку проверять события. Хотя бы раз в неделю смотрите, кто создавал токены, менял политики, отключал проверки и удалял артефакты.

И добавьте две практики, которые экономят нервы: правила хранения артефактов и резервное копирование. Задайте понятные сроки (например, хранить последние N тегов или 30-90 дней для веточных сборок) и расписание бэкапов. Так реестр не разрастется, а восстановление после сбоя не превратится в ручную археологию.

Резервное копирование и восстановление: чтобы не бояться сбоев

Harbor часто становится критичным узлом: если реестр недоступен, сборки и выкладки останавливаются. Поэтому бэкап - часть настройки безопасности Harbor. Вы защищаете не только образы, но и возможность быстро вернуться в строй.

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

RPO и RTO помогают договориться об ожиданиях. RPO - сколько данных вы готовы потерять (например, не больше 1 часа новых тегов). RTO - сколько времени вы готовы ждать восстановления (например, реестр должен подняться за 2 часа). Эти цифры определяют частоту бэкапов и степень автоматизации восстановления.

Храните копии отдельно от Harbor: отдельное хранилище и отдельные права доступа, чтобы компрометация реестра не означала компрометацию бэкапов. Если есть возможность, держите копию в другом дата-центре или хотя бы на изолированном сегменте.

Практичный минимум:

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

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

Правила хранения артефактов: сроки, теги и автоматическая очистка

Без правил хранения реестр быстро превращается в склад. Диск забивается тестовыми сборками, растет стоимость хранения, а еще сложнее понять, что можно удалять без риска. В Harbor политика хранения (retention) помогает держать порядок и снижает риски: меньше случайных деплоев не того образа и проще пройти аудит.

Сначала решите, что должно жить долго. Обычно это релизы и все, что реально крутится в продакшене: образы с версионными тегами (например, 1.4.2), базовые образы команды (runtime, base OS), а также золотые образы, которые используют многие сервисы. Для них срок хранения может быть самым длинным, а удаление - только по строгим правилам.

С тегом latest лучше быть осторожнее. Он удобен, но плохо подходит для контроля: сегодня latest одно, завтра другое. Хорошая практика - хранить latest недолго и не считать его релизным. Для временных тегов (feature-123, pr-45, build-2026-01-11) задайте короткий срок, чтобы реестр сам убирал мусор.

Простой подход обычно выглядит так:

• Релизные версии (семантические теги) хранить дольше всех.
• Для веток и PR хранить последние N сборок или ограничить сроком (например, 7-14 дней).
• Для latest хранить только 1-2 последних образа и не полагаться на него для отката.
• Для продакшена дополнительно закрепить образы, которые используются в развертываниях.

Главный страх при очистке - сломаем откат. Снимается правилами: откатываться нужно не на latest, а на конкретный тег или digest. Тогда вы можете чистить старые сборки по сроку, оставляя гарантированный набор версий (например, последние 5 релизов) и последний образ для каждого важного тега.

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

Пример из практики: как настроить Harbor для одной команды

Сценарий

Одна команда в организации: разработчики собирают сервисы, DevOps поддерживает CI и реестр, а специалист по безопасности задает правила допуска. Harbor развернут внутри периметра, например на корпоративных серверах (в том числе на локально произведенном железе, если это важно для закупок и прозрачности цепочки поставок).

Команда заводит один проект в Harbor, например team-a, и договаривается о потоке: сборка в CI - подпись - сканирование - публикация. Главное правило: в прод можно использовать только образы, которые подписаны и не имеют критичных уязвимостей.

Настройки, которые реально работают

Сначала роли. DevOps делает себя Project Admin в проекте team-a, разработчикам выдает роль Developer (могут пушить), а безопасности - отдельную роль с правами на просмотр отчетов и настройку правил (часто тоже Project Admin, но только в одном проекте). Для CI создают robot-аккаунт, чтобы не хранить личные пароли в пайплайнах.

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

Практичный минимум для пайплайна:

• CI собирает образ и ставит два тега: версию релиза (например, 1.4.2) и короткий тег сборки (например, build-20260111).
• CI подписывает образ (ключ хранится в защищенном хранилище секретов).
• Harbor сканирует образ автоматически при push и еще раз по расписанию (например, раз в ночь), чтобы поймать новые CVE.
• В деплой допускаются только релизные теги, которые подписаны и прошли проверку.

Для хранения команда фиксирует сроки: релизные теги держать 12 месяцев, а ночные сборки - 14 дней. Так реестр не разрастается бесконечно, но аудит и откаты остаются возможными.

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

Частые ошибки и ловушки в настройках безопасности

Самая частая проблема в том, что реестр выглядит настроенным, но реально не защищает. Обычно это происходит не из-за Harbor, а из-за мелких решений на потом.

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

Вторая ловушка - один общий админ-аккаунт на весь Harbor. Пока людей мало, так удобно. Когда появляется инцидент (внезапно пропал тег или изменился webhook), неясно, кто это сделал и почему. Лучше сразу разделить администрирование платформы и владельцев проектов.

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

Чистка артефактов тоже легко превращается в саморазрушение. Удаляют все старое, а потом выясняется, что нужен образ для отката или аудита.

Короткие сигналы, что вы в зоне риска:

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

И отдельная история - бэкапы. Резервные копии могут существовать, но восстановление никто не проверял. Один тестовый restore day раз в квартал обычно дешевле, чем простой продакшена из-за несовместимости версий или потерянных ключей.

Короткий чеклист перед запуском в работу

Перед тем как дать доступ командам и начать заливать образы в реестр контейнеров Harbor, полезно пройтись по нескольким пунктам. Это занимает 10-15 минут, но помогает избежать ситуации, когда все работает, а безопасность держится на честном слове.

Проверьте структуру проектов: разделяйте тест и прод. Отдельные проекты проще защищать и проще объяснять правила. В тестовом проекте можно разрешить экспериментальные образы, а в проде - принимать только подписанные и прошедшие проверку.

Дальше оцените настройки безопасности в Harbor: включено ли сканирование образов контейнеров и что происходит, если найдены критические уязвимости. Пороги блокировки должны быть понятны всем. Например: Critical блокирует развертывание, High требует задачи на исправление до следующего релиза.

Затем проверьте подпись контейнерных образов: кто подписывает (CI или релиз-инженер), какие ключи считаются доверенными и что делаем с неподписанными образами.

Права доступа проверьте строго:

• Есть отдельные проекты для теста и прода.
• RBAC в Harbor настроен так, что лишние роли не выданы на всякий случай.
• Robot-аккаунты имеют минимальные права и ограничены одним проектом.
• Сканирование включено, а пороги блокировки согласованы.
• Подписи настроены, и определено правило доверенных образов.

И наконец, надежность: задайте сроки хранения, договоритесь про теги (например, хранить release-* дольше), включите автоматическую очистку. После этого убедитесь, что резервное копирование Harbor действительно работает: есть расписание, понятное место хранения и хотя бы один подтвержденный тест восстановления.

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

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

Начните с короткого сбора требований: кто пользуется реестром (разработчики, DevOps, безопасность), какие правила обязательны (подписи, запрет критических уязвимостей) и сколько времени вы храните образы. Это напрямую влияет на RBAC, политики сканирования и правила хранения.

Хороший следующий шаг - пилот на одном проекте. Выберите одну команду и один namespace, включите обязательное сканирование при push, подписи для релизных тегов и минимальные роли. Затем зафиксируйте это в простой инструкции на 1-2 страницы: кто создает проекты, кто выдает доступ, что считается релизом, что делать при провале сканирования.

Чтобы настройка безопасности Harbor не деградировала со временем, запланируйте регулярные проверки:

• Раз в месяц: аудит пользователей и прав (лишние аккаунты, неиспользуемые токены).
• Раз в спринт: выборочная проверка подписей на релизных образах.
• Раз в неделю: просмотр итогов сканирования и тренда по критическим уязвимостям.
• Раз в квартал: тест восстановления из резервной копии.

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

Если вы строите реестр и инфраструктуру полностью on-prem, полезно заранее продумать платформу и поддержку. GSE.kz (gse.kz) как производитель серверов и системный интегратор в Казахстане может помочь со спроектированной под нагрузку инфраструктурой, системной интеграцией и организацией 24/7 сопровождения, чтобы регламенты работали не только на старте.