Comments 5
Непонятно, каким из перечисленных требований не удовлетворил Harbor. Там нет генерации сертификатов для выдачи токенов, потому что Harbor не использует этот штатный механизм (в этом они не молодцы, а вы молодец), но сертификаты часто генерировать и не нужно. Самый гибкий контроллер доступа, который позволяет фильтровать по тэгам (чего не может ни Harbor, ни ваш проект) — https://github.com/cesanta/docker_auth. Если бы ваш GUI стыковался с ним, генерируя конфиг, ваш проект был бы проще, а результат функциональнее.
P. S. Склейка SQL из строк в коде — караул.
Генерация сертификатов на стороне сервиса, на момент реализации, мне казалась логичным решением. Хотя и соглашусь, что по факту они генерируются один раз при развертывании. Что касается фильтра по тэгам, то он у меня реализован на странице самого репозитория.
Про SQL строки, мне честно говоря это тоже видится, мягко говоря, не очень. Но я не хотел использовать всякие варианты с hibernate. Такая склейка, по большей части, обусловлена адаптацией под концепцию со стороны фреймворка React-Admin. Готов выслушать предложения по оптимизации этой части.
Если я правильно понял, то представленная в статье Админка по сути является проксёй для docker container registry, которая обеспечивает безопасность репозитория (user management) и Web GUI
Не совсем прокси т.к. запросы к реестру выполняются напрямую. Это сбоку стоящий сервис auth + UI на который сам registry перенаправляет клиентские запросы. После получения токена, клиент напрямую общается с registry.
Только через такой механизм аутентификации (silly или token) можно организовать раздельный доступ к container regitry.
Админка для Private Docker Registry (Registry Admin)