Я столкнулся с интересной ситуацией, когда мне нужно клонировать частное репозиторий github в докер-контейнер, который я использую в Kubernetes. Первоначально я пытался использовать монтирование gitRepo, однако наличие ключа OAuth в моем манифесте развертывания недопустимо, и я хотел бы использовать ключ развертывания репозитория, а не ключ OAuth, прикрепленный к моей учетной записи GitHub.

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

Ограничения

Мне нужно следующее:

Репо внутри контейнера, которое я могу периодически снимать, пока мой контейнер работаетДоступ к репо должен осуществляться с помощью ключа развертывания GitHubКлюч должен храниться в безопасности (в секрете Kubernetes) и не храниться в образе докераРепо должно быть разделено между двумя контейнерами в одном модуле: один пишет, а другой читаетВозможные решения:Смонтируйте ключи SSH как секреты и клонируйте:

Я попытался клонировать репозиторий в emptydir с помощью скрипта bash, запущенного в отдельном модуле (этот скрипт должен работать в любом случае, я использую его и для других целей), однако затем я столкнулся с проблемой получения ключей SSH в порт назначенияЭтот вопрос об этой проблеме, однако, похоже, нет способа сделать это. Я смог получить ключи с помощью секретного монтирования, но затем разрешения были установлены на 777. Чтобы обойти это, я установил ключи в/test/ каталог, а затем попыталсяcp их в/root/.ssh/, Это дало мне эти странные ошибки:

cp: '/test/id_rsa' and '/root/.ssh/id_rsa' are the same file
cp: '/test/id_rsa.pub' and '/root/.ssh/id_rsa.pub' are the same file

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

cat: /keys/id_rsa: input file is output file
cat: /keys/id_rsa.pub: input file is output file

Как только я исправил пути, он ничего не сделал и молча провалился.kubectl execвход в контейнер не показывал файлов в/root/.ssh/.

Я думаю, что я в значительной степени достиг дна этого пути, поэтому я не думаю, что это будет решением.

Настройка ssh для игнорирования ключевых разрешений

Если у SSH есть способ игнорировать разрешения для ключей - по умолчанию он обеспечивает 644 или менее, я полагаю - тогда вышеупомянутое решение могло бы быть возможным. Я удивлен, что не нашел способов сделать это, но мой google-fu всегда отображал результаты, говоря, что вам просто нужно правильно установить разрешения.

Некоторый другой способ получить ключи в контейнере безопасно

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

Клонировать с помощью ключа OAuth внутри контейнера

Я думал о попытке использовать ключ OAuth в переменной окружения, а затем использовать его для клонирования репозитория по HTTPS. Это не идеально, но если это сработает, я возьму это. Единственное, что мешает мне сделать это сейчас, это то, что я не могу использовать ключ развертывания. Если есть способ использовать OAuth с ключом развертывания, я еще не нашел его, но это может быть решением, если кто-то знает больше.

Клонирование в образе докера

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

Я чувствую, что мне нечего попробовать, поэтому любые предложения могут стоить того.

Подобные вопросы

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

Этот вопрос говорит о получении ключей SSH в контейнеры в Kubernetes, однако я не намерен использовать git поверх SSH, так что я думаю, что это должен быть собственный вопрос.