Używanie tego samego klucza wdrażania dla wielu projektów Github

Github nie pozwala na użycie tego samego klucza SSH dla więcej niż jednego projektu, co byłoby bardzo przydatne w niektórych przypadkach (np. Serwer CI zajmujący się projektem z prywatnymi podmodułami). Widziałem różne wątki, które zdają się mówić, że to ograniczenie istnieje ze względów bezpieczeństwa, ale nie widziałem jeszcze przekonującego wyjaśnienia, jakie dokładnie ryzyko to mogłoby spowodować.

Zwróć uwagę, że fakt, że Github nie pozwala na ponowne użycie kluczy na poziomie konta, ma sens (dwóch użytkowników nie powinno udostępniać kluczy). Kwestionuję tylko ograniczenie dotyczące kluczy wdrażania .

I żeby było jasne, nie szukam obejść (utwórz fikcyjnego użytkownika, użyj wielu kluczy, ...), ale tylko po to, aby uzyskać wiarygodne wyjaśnienie tego ograniczenia w Kluczach Wdrażania.

Powiązane wątki:

• Jeden pokazujący obejście
• Jeden omawiający ten problem, ale nigdzie się nie wybiera

Jedynym powodem, zilustrowanym przez obejście, do którego się odwołujesz (utworzenie pojedynczego użytkownika „kompilacji” lub udostępnienie tego samego dla id_rsa.REPONAME.pubkażdego repozytorium) jest:

unikaj udostępniania klucza publicznego / prywatnego innym użytkownikom

Nawet jeśli nie miałoby to miejsca w twojej sytuacji (budowanie wielu projektów), zezwolenie na ponowne użycie tego samego klucza ssh otworzyłoby możliwość współdzielenia tego samego klucza przez dwóch różnych użytkowników, co zniweczyłoby cel uwierzytelniania .

Uwierzytelnianie oznacza:
„użycie określonego klucza SSH powinno oznaczać, że powinieneś wiedzieć, kto go używa”.

Strona GitHub „ Zarządzanie kluczami wdrażania ” zawiera szczegółowe informacje na temat różnych kont używających ssh:

• Przekazywanie agentów SSH : przekazywanie agentów wykorzystuje klucze SSH już skonfigurowane na lokalnej maszynie programistycznej, gdy łączysz się przez SSH z serwerem i uruchamiasz polecenia git.
  Możesz selektywnie zezwolić zdalnym serwerom na dostęp do lokalnego agenta ssh, tak jakby działał na serwerze.
  Nie ma więc potrzeby replikowania klucza prywatnego na serwerze.

• Użytkownicy komputerów : (to jest strategia „konta fikcyjnego”) Dołącz klucz do konta użytkownika. Ponieważ to konto nie będzie używane przez człowieka, nazywa się je użytkownikiem maszyny.
  Potraktowałbyś tego użytkownika tak samo, jak człowieka, dołączając klucz do konta użytkownika maszyny tak, jakby było to normalne konto.
  Przyznaj współpracownikowi konta lub zespołowi dostęp do repozytoriów, do których potrzebuje dostępu.
  Tak więc jeden klucz prywatny powiązany z jednym „użytkownikiem maszyny”, po jednym na serwer.

( DHa zwraca uwagę w komentarzach na numer limitu klucza wdrażania oraz fakt, że możesz mieć tylko jedno konto użytkownika maszyny)

• Klucz wdrożenia (jeden na repozytorium GitHub) Klucz SSH przechowywany na serwerze i zapewniający dostęp do pojedynczego repozytorium w serwisie GitHub.
  Ten klucz jest dołączany bezpośrednio do repozytorium zamiast do konta użytkownika .
  Zamiast przechodzić do ustawień konta, przejdź do strony administratora docelowego repozytorium.
  Przejdź do „ Deploy Keys” i kliknij „ Add deploy key”. Wklej klucz publiczny i prześlij.

Tym razem klucz ssh nie jest dołączony do użytkownika (któremu można przyznać dostęp do kilku repozytoriów), ale do jednego repozytorium.
Przyznanie dostępu ssh do kilku repozytoriów byłoby odpowiednikiem „użytkownika maszyny”.

W zakresie uwierzytelnienia :

• używanie tego samego klucza do kilku repozytoriów jest w porządku, gdy jest wykonywane przez użytkownika (który ma wspomniany klucz powiązany z jego kontem)
• używanie tego samego klucza dla kilku repozytoriów NIE jest w porządku, gdy klucz jest dołączony przez repozytorium, ponieważ w ogóle nie wiesz, kto miał dostęp do czego.
  Różni się to od „użytkownika maszyny”, w którym „użytkownik” jest deklarowany jako współpracownik dla wielu repozytoriów.
  Tutaj (klucz wdrażania) nie ma „współpracownika” , tylko bezpośredni dostęp ssh do repozytorium.

Niestety, jest to scenariusz, w którym github po prostu błędnie interpretuje różnicę między parą kluczy a kontem lub projektem.

Ponieważ para kluczy jest używana do uwierzytelniania i autoryzacji, w rzeczywistości jest to tożsamość. Konta Github to kolejna tożsamość. Połączenie kont github z parami kluczy skutecznie ustanawia mapowanie 1: N między tożsamościami opartymi na kontach github a tożsamościami par kluczy.

I odwrotnie, github wymusza mapowanie 1: N projektów na tożsamości oparte na parach kluczy. Prawdziwym odpowiednikiem tego świata jest to, że istnieją drzwi zapewniające dostęp do projektu, które może otworzyć wiele różnych osób. Ale kiedy któryś z nich dostanie klucz do drzwi, nie może już dostać żadnych innych kluczy do innych drzwi.

Nie należy często ponownie używać kluczy z punktu widzenia powstrzymywania naruszeń, jeśli klucz zostanie narażony na szwank. Ale to tylko dobra polityka administracyjna . To nie ma sensu, aby zapobiec klucza zostały użyte więcej niż raz na zasady . To, że istnieją klucze do niektórych drzwi, które nigdy nie są ponownie używane, cóż, znowu to zależy od polityki .

Nieco bardziej złożonym poglądem jest zilustrowanie kluczowych par jako ról . Możesz posiadać wiele par kluczy, a zatem pełnić wiele ról. Klucz prywatny uwierzytelnia Cię do roli.

Mapowanie kluczy wdrażania Github w projektach stwierdza, że ​​rola nigdy nie może obejmować więcej niż jednego zadania. Rzadko jest to realistyczne.

Oczywiście żaden z nich nie zmienia tego, na co pozwala github.

Zajęło mi dużo czasu, aby zracjonalizować konsekwencje i wymyślić taki scenariusz.

Wyobraź sobie, że tworzysz jeden klucz wdrażania dla użytkownika, który został przypisany do wielu repozytoriów. Teraz chcesz unieważnić ten klucz, ale jest używany w wielu miejscach. Dlatego zamiast móc cofnąć cały dostęp, możesz nieumyślnie odwołać tylko częściowy dostęp.

Może się to wydawać korzyścią, ale ta relacja typu „wiele do jednego” jest w rzeczywistości z natury niepewna, biorąc pod uwagę czynnik ludzki. Dzieje się tak, ponieważ nie możesz być pewien, czy naprawdę cofnąłeś cały dostęp bez sprawdzania każdego repozytorium i porównania każdego klucza publicznego indywidualnie, w przypadku, gdy zapomniałeś, gdzie faktycznie go przypisałeś.

Zdecydowanie frustrujące jest przypisywanie i zarządzanie tak wieloma unikalnymi kluczami, ale implikacje bezpieczeństwa są jasne, jeśli chodzi o sposób, w jaki GitHub ustanowił swoją politykę: kiedy unieważnisz klucz, masz gwarancję odwołania całego dostępu przyznanego przez ten klucz, ponieważ jest on używany tylko w jednym miejscu .