k
Для этих обоих кейсов и пытаюсь понять насколько это может быть опасно, судя по логике всё должно быть норм, но однозначного ответа так нигде и не нашёл.
Size: a a a
2020 April 24
i
Если основное гитлаб - лучше 2 вариант
k
Единственное, что кмк там для нормального пуша/пулла надо sticky session какой-то, чтобы эти операции проходили через 1 сервер
Почему? Там же по токенам авторизация
i
Почему? Там же по токенам авторизация
Зато если нужен ldap напрмер просто для юзеров - хуй там
k
Если основное гитлаб - лучше 2 вариант
Ну окей, то есть со вторым вариантом оно будет норм работать, тогда я не вижу причин почему не стоит попробовать первый
i
А что ты имеешь в виду над "поверх"? Если про storage - нет гарантии, что они одинаково хранят
k
Зато если нужен ldap напрмер просто для юзеров - хуй там
Так регистри же, перед тем как выполнить запрос, тебе нужно получить токен, хоть лдап хоть что-то ещё
k
А что ты имеешь в виду над "поверх"? Если про storage - нет гарантии, что они одинаково хранят
одинаково, харбор юзает обычный docker registry в качестве бэкенда
i
Так регистри же, перед тем как выполнить запрос, тебе нужно получить токен, хоть лдап хоть что-то ещё
Тебе нужно авторизоваться через гитлаб - и не факт, что юзеры ldap и гитлаба, даже привязанного к нему совпадают
k
Тебе нужно авторизоваться через гитлаб - и не факт, что юзеры ldap и гитлаба, даже привязанного к нему совпадают
А какая разница, у регистри есть CA, гитлаб через него токены выпускает, харбор тоже
i
А какая разница, у регистри есть CA, гитлаб через него токены выпускает, харбор тоже
Ну смотри, у меня есть например imagepullsecret
i
там должен быть логин/пасс
i
Я создаю в ldap сервисного юзера - все збс. В гитлабе этого юзера не будет, а registry отдельно к ldap привязать нельзя
i
А какая разница, у регистри есть CA, гитлаб через него токены выпускает, харбор тоже
Я про ситуацию без харбора
k
Я создаю в ldap сервисного юзера - все збс. В гитлабе этого юзера не будет, а registry отдельно к ldap привязать нельзя
Окей, докер идёт в регисти, тот редиректит его запрос в гитлаб, который выступает в качестве auth-endpoint
конфиг регистри при этом вот такой:
конфиг регистри при этом вот такой:
auth:
token:
realm: https://gitlab.example.com/jwt/auth
service: container_registry
issuer: gitlab-issuer
rootcertbundle: /root/certs/certbundle
i
Окей, докер идёт в регисти, тот редиректит его запрос в гитлаб, который выступает в качестве auth-endpoint
конфиг регистри при этом вот такой:
конфиг регистри при этом вот такой:
auth:
token:
realm: https://gitlab.example.com/jwt/auth
service: container_registry
issuer: gitlab-issuer
rootcertbundle: /root/certs/certbundle
Тогда в гитлаб должен замапиться этот юзер
k
гитлаб имея доступ к CA генерит jwt токен и одаёт его клиенту
i
В нашем варианте, каждый такой юзер - 19$ в месяц
k
затем клиент с этим токеном идёт в регистри
i
затем клиент с этим токеном идёт в регистри
при ldap и попытке auth - если гитлаб получит юзера, он его создаст и добавит в лицензию