A
Size: a a a
2020 March 23
k
Alexander
Куда подсунуть?
A
полагаю что проект будет создаваться при пуше имаджа, rbac для доступа к нему я бы решал на стороне харбора, но для gitlab-ci гитлаб сам выпускал бы токены исходя из своих настроек безопасности, приватный ключ-то у него есть
Гитлаб ничего не знает про авторизационную модель харбора. А харбор ничего не знает про модель гитлаба.
A
И хранится в их собственных базах
A
но ведь имея private key я могу выпустить токен и запушить образ в харбор в любое место, он должен будет это увидеть, не так-ли?
Да, ты можешь взять приватный ключ харбора и подложить гитлабу. Они сможет пушить любые образы в хранилище, но эти образы не будут иметь никакого смысла с т.з. харбора. Т.к. в его базе никаких данных про них не будет.
k
Alexander
Да, ты можешь взять приватный ключ харбора и подложить гитлабу. Они сможет пушить любые образы в хранилище, но эти образы не будут иметь никакого смысла с т.з. харбора. Т.к. в его базе никаких данных про них не будет.
ну как нет, он же в registry api смотрит, вот и увидит что появились некие новые образы
A
Можно, конечно, заранее создавать нужные проекты и rbac-и через api харбора, чтобы можно было через него потом получать доступ к образам, запушенным гитлабом. Но, ИМХО, проще уж тогда переехать целиком на гитлабный реджистри. Или поднять отдельный.
TF
Alexander
Можно, конечно, заранее создавать нужные проекты и rbac-и через api харбора, чтобы можно было через него потом получать доступ к образам, запушенным гитлабом. Но, ИМХО, проще уж тогда переехать целиком на гитлабный реджистри. Или поднять отдельный.
слился ;)
A
слился ;)
Я изначально пытаюсь объяснить, что идея двух господ у одного слуги довольно плоха.
A
По сути, гитлаб и харбор делают одно и то же.
A
А docker distribution для них - низкоуровневый сторадж.
TF
Alexander
Я изначально пытаюсь объяснить, что идея двух господ у одного слуги довольно плоха.
я могу заванговать, что допустим изобретут патч для двоих, но жить оно скорей не будет к.м.к., ибо выгоды нет