Використання одного і того ж ключа розгортання для декількох проектів github

Github не дозволяє використовувати один і той же ключ розгортання ssh для більш ніж одного проекту, що було б дуже корисно в деяких випадках (наприклад, сервер CI, що має справу з проектом з приватними підмодулями). Я бачив різні теми, які, здається, говорять про те, що це обмеження існує з "міркувань безпеки", але я ще не побачив переконливого пояснення щодо того, який саме ризик це може викликати.

Зауважте, що той факт, що Github не дозволяє повторно використовувати ключі рівня облікового запису, має сенс (двоє користувачів не повинні ділитися ключами). Це лише обмеження щодо ключів розгортання, яке я допитую.

І щоб бути зрозумілим, я не шукаю обхідних шляхів (створити фіктивного користувача, використовувати кілька ключів, ...), а лише правдоподібне пояснення цього обмеження на ключі розгортання.

Пов’язані теми:

• Один, який показує обхідний шлях
• Той, хто обговорює проблему, але насправді нікуди не йде

Єдиною причиною, проілюстрованою обхідним шляхом, на який ви посилаєтесь (створення одного користувача "побудови" або спільне використання одного і того ж id_rsa.REPONAME.pubрепо), є:

уникайте спільного використання відкритого / приватного ключа для різних користувачів

Навіть незважаючи на те, що у вашій ситуації це не так (побудова декількох проектів), повторне використання одного ключа ssh відкриє можливість двом різним користувачам спільно використовувати один і той же ключ ssh, що призведе до порушення цілей автентифікації .

Аутентифікація означає:
"використання певного ключа ssh має означати, що ви повинні знати, хто ним користується".

Сторінка GitHub " Керування ключами розгортання " деталізує різні облікові записи за допомогою ssh:

• Переадресація агента SSH : переадресація агента використовує ключі SSH, уже налаштовані на вашій локальній машині розробки, коли SSH входить на ваш сервер і запускає команди git.
  Ви можете вибірково дозволити віддаленим серверам отримувати доступ до вашого локального агента ssh, як якщо б він працював на сервері.
  Тож не потрібно копіювати ваш приватний ключ на сервері.

• Користувачі машини : (це стратегія "фіктивного облікового запису") Приєднайте ключ до облікового запису користувача. Оскільки цей обліковий запис не буде використовуватися людиною, він називається користувачем машини.
  Ви поводились би з цим користувачем так само, як із людиною, хоча б прикріпити ключ до облікового запису користувача машини, як якщо б це був звичайний обліковий запис.
  Надайте співробітнику облікового запису або команді доступ до репозиторіїв, до яких йому потрібен доступ.
  Отже, один приватний ключ пов'язаний з одним "користувачем машини", по одному на сервер.

( DHa вказує в коментарях на обмежене число ключа розгортання, а також на те, що ви можете мати лише один обліковий запис користувача машини)

• Розгортання ключа (по одному на репозиторій GitHub) SSH, який зберігається на сервері та надає доступ до одного репо на GitHub.
  Цей ключ прикріплюється безпосередньо до репозиторію, а не до облікового запису користувача .
  Замість того, щоб переходити до налаштувань свого облікового запису, перейдіть на сторінку адміністратора цільового репо.
  Перейдіть до " Deploy Keys" та натисніть " Add deploy key". Вставте відкритий ключ і надішліть.

Цього разу ключ ssh прикріплений не до користувача (для якого ви можете надати доступ до кількох репо), а до одного репо.
Надання доступу ssh для кількох репо буде еквівалентом "користувача машини".

Що стосується автентифікації :

• використання одного і того ж ключа для кількох репозиторіїв - це нормально, коли це робить користувач (який зазначений ключ пов’язаний з його / її обліковим записом)
• використання одного і того ж ключа для декількох репо НЕ гаразд, коли ключ приєднується репо, оскільки ви взагалі не знаєте, хто до чого отримував доступ.
  Це відрізняється від "користувача машини", де "користувач" оголошується співавтором для багатьох репо.
  Тут (ключ розгортання) немає "співавтора" , лише прямий доступ ssh, що надається репо.

На жаль, це сценарій, коли github просто неправильно інтерпретує різницю між парою ключів та рахунком або проектом.

Оскільки пара ключів використовується для автентифікації та авторизації, це фактично ідентичність. Облікові записи Github - це ще одна ідентичність. Підключення облікових записів github до пар ключів ефективно встановлює співвідношення 1: N між ідентифікаціями, заснованими на облікових записах github, та ідентифікаторами пар ключів.

І навпаки, github застосовує 1: N відображення проектів до ідентифікацій на основі пар ключів. Реальний аналог світу полягає в тому, що є двері, що забезпечують доступ до проекту, яку можуть відкрити багато різних людей. Але як тільки хтось із них отримає ключ від дверей, вони не зможуть отримати будь-які інші ключі від будь-яких інших дверей, ніколи більше.

Є сенс не повторно використовувати ключі часто з точки зору, що містять порушення, якщо ключ стає скомпрометованим. Але це лише хороша адміністративна політика . Не має сенсу перешкоджати використанню ключа в принципі більше одного разу . Що є деякі ключі для деяких дверей, які ніколи не використовуються повторно, ну, знову ж таки, це залежить від політики .

Трохи складніший погляд полягає в тому, щоб проілюструвати пари ключів як ролі . Ви можете володіти багатьма парами ключів, а отже, жити в багатьох ролях. Приватний ключ автентифікує вас на роль.

Зіставлення ключів розгортання Github у проектах свідчить, що роль ніколи не може охоплювати більше одного завдання. Це рідко реалістично.

Звичайно, жодне з них не змінює того, що дозволяє github.

Мені знадобилося багато роздумів, щоб обґрунтувати наслідки, і я придумав такий сценарій.

Уявіть, що ви створюєте єдиний ключ розгортання для користувача, якого ви призначили кільком сховищам. Тепер ви хочете відкликати цей ключ, але він використовується в кількох місцях. Отже, замість можливості скасувати весь доступ, ви ненавмисно можете скасувати лише частковий доступ.

Це може звучати як вигода, але ці стосунки багато до одного насправді є невпевненими в собі, коли врахувати людський фактор. Це пов’язано з тим, що ви не можете точно знати, чи дійсно ви скасували весь доступ, не перевіривши кожне сховище, і порівняти кожен відкритий ключ окремо у тому випадку, якщо ви забули, де ви насправді його призначили.

Безумовно, викликає розчарування призначення та керування такою кількістю унікальних ключів, але наслідки для безпеки зрозумілі з того, як GitHub запровадив свою політику: коли ви відкликаєте ключ, ви гарантовано скасуєте весь доступ, наданий цим ключем, оскільки він використовується лише в одному місці .