2011-08-17 13 views
19

Zastanawiam się, czy ktoś ma dobry, czysty i bezpieczny sposób zarządzania dostępem do repozytorium organizacji Github na swoich serwerach?zarządzanie kluczami publicznymi ssh w repozytoriach organizacji Github

Wygląda na to, że klucze do pubu można dołączać tylko do konta osobistego i nie można ograniczyć dostępu wyłącznie do organizacji.

Mamy serwer beta, na którym umieszczamy wiele projektów, więc wdrażaj klucze, ponieważ muszą być unikatowe, nie są idealne. Byłoby miło dać globalny dostęp do organizacji, ale nie chcę dać serwerowi, który mamy freelancerzy, pełny dostęp do mojego osobistego konta (serwer dostaje dostęp do organizacji, co jest dobre, ale także do moich osobistych projektów i każdej innej organizacji, do której należę, co jest złe).

Dwa obejścia, które widzę, to albo skonfigurować fikcyjnego użytkownika github, aby przejść, co wydaje się głupie, albo włączyć przekazywanie agenta ssh, co wydaje się ryzykiem bezpieczeństwa (nie jestem najlepszym administratorem serwera).

Znajomy zaproponował ustawienie serwera jako pilota do wypychania, ale wydaje się, że jest to rozwiązanie wspomagające zespół.

Chciałbym myśleć, że istnieje łatwiejszy sposób na ustanowienie dostępu do repozytorium organizacji, ponieważ uważam, że byłaby to podstawowa potrzeba dla wszystkich.

Jestem uszy, jeśli ktoś chciałby podzielić się czymś, co działa/działa dla ich organizacji github.

Prawdopodobnie po prostu ugryzę kulę i utworzę smoczego użytkownika github i zadzwonię do niej dzień, muszę wykonać pracę.

+0

Dlaczego Twoim zdaniem przekazywanie agentów stanowi zagrożenie dla bezpieczeństwa? Czy nie rozumiesz, jak to działa? – Tekkub

Odpowiedz

6

alternatywą do odpowiedzi z sergey_mo (i jako bezpośrednia odpowiedź ostateczna zapytania Michał Szajbe'S) jest tworzenie wielu kluczy ssh co zostało udokumentowane przez chalien na githib:

https://gist.github.com/jexchan/2351996

+1

Stara odpowiedź, wiem ... Ale tutaj jest [działający link] (https://gist.github.com/jexchan/2351996) (Zakładam, że to oryginalny dokument/informacje powiązane z powyższą odpowiedzią). – mhulse

+0

Właśnie zaktualizowałem link w poście. –

2

Nie rozumiem, dlaczego dodanie konta dummy jest tak złe dla automatycznego wdrażania, o ile przed uruchomieniem GitHub uruchamiasz własny serwer beta jako obszar testowy. To znaczy, jeśli chcesz, aby betacode był prywatny.

Zwykły sposób GitHub polega na dodaniu wszystkich współpracowników i po prostu na stabilnym projekcie i widełkach beta. Automatycznie pobierzesz bieżącą wersję beta do beta serwera w celu przetestowania (nie potrzebujesz potrzebnego klucza ssh), a jeśli twoje testy się powiedzie, nastąpi połączenie fuzji z beta fork do stabilnego projektu.

+0

Myślę, że to nie jest najgorsza rzecz na świecie, miałem tylko nadzieję, że będę w stanie zarządzać dostępem do organizacji za pomocą jednego konta bez konieczności żonglowania logowaniem jak kiedyś. Ma to jednak sens, ponieważ organizacje nie są użytkownikami. Dzięki za wejście. – digitaldreamer

+1

Problem polega na tym, że jeśli korzystasz z fałszywego konta w dowolnej DVCS, nie możesz winić ani pisać adnotacji/kto to zrobił, co jest bardzo przydatne, gdy jedno z kont zostanie zaatakowane przez hakerów i nie musisz wysyłać nowych kluczy do wszystkich . – Lars

0

Możesz obejść ten problem, uruchamiając aplikacje przez różnych użytkowników (po jednym użytkowniku na aplikację). Mam na myśli użytkowników serwerów, a nie użytkowników github. To dobra praktyka na wielu serwerach aplikacji.

Każdy użytkownik ma swoją własną parę kluczy ssh, więc masz wiele unikalnych kluczy instalacyjnych (jeden na repozytorium github).

Używam tego podejścia, gdy tylko jest to możliwe. Jednak zdarzają się sytuacje, w których jeden użytkownik uruchamia więcej niż jedną aplikację i prawdopodobnie nie można tego zrobić przy użyciu kluczy wdrażania github. Poszukuję również dobrego rozwiązania takich przypadków.

1

Mała uwaga na temat CI:
Na przykład, jeśli używasz Jenkins i trzeba to dostęp do więcej niż 1 projekt trzeba będzie:
1. dodać klucz publiczny do jednego konta użytkownika github
2. Dodać ten użytkownik jako właściciel (aby uzyskać dostęp do wszystkich projektów) lub jako współpracownik w każdym projekcie.

Wiele kluczy publicznych dla jednego użytkownika systemu nie będzie działać, ponieważ GitHub znajdzie pierwszy dopasowane wdrożyć klucz i odeśle błąd jak „Błąd: Pozwolenie na użytkownika/repo2 odmówiono użytkownika/repo1”

http://help.github.com/ssh-issues/

Powiązane problemy