управление открытыми ключами ssh в репозиториях организаций github
Мне было интересно, есть ли у кого-нибудь хороший, чистый, безопасный способ управления доступом к репозиторию организации github на своих серверах?
похоже, что вы можете прикреплять ключи pub только к своему личному кабинету и не можете ограничивать доступ только к организации.
У нас есть бета-сервер, где мы помещаем несколько проектов, поэтому ключи развертывания, потому что они должны быть уникальными, не идеальны. Было бы неплохо предоставить глобальный доступ к организации, но я не хочу давать сервер, на котором у нас есть фрилансеры, полный доступ к моему личному кабинету (сервер получает доступ к организации, что хорошо, но и к моим личным проектам и к любой другой организации, к которой я принадлежу, что плохо).
два обходных пути, которые я вижу, - это либо настроить фиктивного пользователя github, чтобы пройти, что кажется глупым, либо включить переадресацию агента ssh, что кажется риском для безопасности (я не лучший сервер-администратор).
друг предложил создать сервер как удаленный, чтобы нажать, но это похоже на решение для пластыря.
Я хотел бы думать, что есть более простой способ настроить доступ для РЕПО организации, поскольку я думаю, что это будет фундаментальная потребность для всех.
Я все уши, если кто-то хотел бы поделиться чем-то, что имеет/работает для их организации github.
Я, вероятно, просто укушу пулю и создам фиктивного пользователя github и назову его днем, мне нужно закончить работу.
4 ответов
альтернативой ответу от sergey_mo (и в качестве прямого ответа на последний вопрос Михаила Зайбе) является создание нескольких ключей ssh, как задокументировано chalien на githib:
Я не понимаю, почему добавление фиктивной учетной записи так плохо для автоматического развертывания, если вы запускаете свой собственный бета-сервер в качестве промежуточной области перед нажатием на GitHub. То есть, если вы хотите, чтобы бетакод был приватным.
обычным способом GitHub было бы добавить всех сотрудников и просто иметь стабильный проект и бета-вилку. Вы автоматически потянете текущую бета-версию на бета-сервер для тестирования (там не нужен ключ ssh), и если ваши тесты пройдут успешно, вы потянете слияние из бета-вилки в стабильный проект.
небольшая заметка о CI:
Например, если вы используете Jenkins и вам нужно получить доступ к более чем 1 проекту, вам нужно:
1. добавить открытый ключ к одной учетной записи пользователя GitHub
2. добавьте этого пользователя как владельца (для доступа ко всем проектам) или как сотрудника в каждом проекте.
многие открытые ключи для одного пользователя системы не будут работать, потому что GitHub найдет первый соответствующий ключ развертывания и отправит обратно ошибку, как "ошибка: разрешение пользователю / repo2 отказано в user / repo1"
вы можете обойти это, запустив свои приложения разными пользователями (по одному пользователю на приложение). Я имею в виду пользователей сервера, а не пользователей github. Это хорошая практика в любом случае на серверах multi-app.
каждый пользователь имеет собственную пару ключей ssh, поэтому у вас есть много уникальных ключей развертывания (по одному на репозиторий github).
Я использую этот подход, когда это возможно. Однако есть ситуации, когда более одного приложения запускается одним пользователем, и это, вероятно, не может быть сделано с помощью github развернуть ключи. Я тоже ищу хорошее решение для таких случаев.