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

Реестры предоставляют образы, которые запускают ноды Docker, и артефакты, которые публикуют Build Workers. Opfield хранит учётные данные реестра и решения о доступе отдельно от конфигурации рабочей нагрузки, использующей образ. Благодаря этому оператор может менять доступ к реестру, не раскрывая пароль в Container, Deployment или определении источника.

Определите политику доверия к образам

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

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

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

Настройте доверенный доступ

Храните учётные данные приватного реестра в Opfield и ограничивайте их нужным путём сборки или среды выполнения. Настраивайте отдельный доверенный источник token-service, только если реестр намеренно делегирует этой службе Bearer-аутентификацию. До развёртывания в рабочей среде проверьте адрес реестра, доступ к репозиторию и доверие к сертификату.

Не помещайте пароли реестра в ссылки на образы, URL Git, аргументы сборки, журналы, имена архивов или снимки экрана. Если аутентификация завершилась ошибкой, проверьте учётные данные реестра, права на репозиторий, конфигурацию token-service и сетевой доступ целевой ноды. Повторные перезапуски рабочей нагрузки не исправят этот уровень.

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

Внутренний реестр Distribution в Opfield хранит одобренные результаты сборки по неизменяемому дайджесту. Он сохраняет материалы, необходимые активным приложениям, версиям для отката, выполняющимся операциям, закреплённым ссылкам и недавним успешным сборкам. Для внутреннего использования Opfield публичный Domain ему не нужен. Реестр показывает фактически занятый его томом объём, который обновляется примерно раз в 10 минут.

Наличие образа во внутреннем реестре не делает его публичным релизом. Рабочую нагрузку всё равно нужно настроить на этот дайджест, успешно загрузить образ на целевую ноду и пройти эксплуатационную проверку.

Необязательный доступ внешнего клиента Docker

Доступ внешнего клиента Docker — отдельное право по тарифу и отдельная конфигурация Ingress, которая работает на стандартных нодах Ingress с nginx. Для него нужны выбранное размещение nginx, Domain, TLS-сертификат и токен с областью репозитория или действия. После окончания льготного периода лицензии внешняя точка доступа и её настройки сохраняются, но конечная точка выдачи токенов не выдаёт новые токены до продления тарифа. Каждый запрос токена заново проверяет текущую авторизацию и право по тарифу, поэтому их отзыв действует на последующие обращения.

Включайте внешний доступ, только если он нужен реальному клиентскому процессу. До использования в автоматизации проверьте TLS, аутентификацию и минимальные права на репозиторий или действие с клиента вне рабочей среды. Удаление конфигурации Ingress прекращает клиентский доступ, но не удаляет артефакты из внутреннего хранилища.

Рекомендации при инцидентах и очистке

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

Жизненный цикл учётных данных

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

Если учётные данные раскрыты, отзовите их в реестре, замените в Opfield и найдите сборки или загрузки за время возможной утечки. Замена только копии в Opfield не делает исходный секрет у поставщика недействительным. Проверьте журналы на неожиданные репозитории или дайджесты, не копируя содержащие секреты заголовки в запись инцидента.

Операторские детали: сбои загрузки и хранение

При ошибке аутентификации последовательно отделите доступность DNS/TLS, сопоставление реестра, отклонение учётных данных, источник token-service, права на репозиторий и отсутствие манифеста. Проверяйте точные репозиторий и дайджест из затронутого пути выполнения, а не с посторонней рабочей станции администратора.

До очистки внутреннего реестра или отключения внешнего доступа определите дайджесты активных рабочих нагрузок, слотов Deployment для отката, выполняющихся сборок, закреплённых артефактов и недавних заведомо исправных релизов. Если нужный артефакт удалён, повторно опубликуйте или соберите его из проверенной ревизии источника до изменения рабочей нагрузки. Не заменяйте его непроверенным тегом с тем же именем.