Rozdziel automatyzację i administrację osobistą
Pipeline API raportowania musi wybrać zatwierdzony artefakt i wywołać kontrolowaną akcję wydania. To nie wymaga automatycznie tworzenia użytkowników, zmiany rozliczeń ani odczytu każdego sekretu aplikacji. Zacznij od inwentarza uprawnień i chronionego środowiska testowego; trzymaj poświadczenia z dala od dokumentów, repozytoriów i przykładowych logów.
Ludzki dostęp do odzyskiwania powinien pozostać oddzielony, aby unieważnienie poświadczenia wdrożeniowego nie usuwało jedynej ścieżki dochodzenia. Wskaż upoważnionego opiekuna i niezależną weryfikację hosta. Drugi nieograniczony klucz to kolejne poświadczenie, a nie węższa rola.
Opisz dokładnie dozwoloną operację
| Możliwość | Potrzebne? | Granica |
|---|---|---|
| Odczyt zatwierdzonego artefaktu | Tak | Konkretne repozytorium/wersja |
| Wywołaj akcję wydania | Tak | Stała aplikacja i środowisko |
| Odczyt każdego sekretu środowiska uruchomieniowego | Unikaj | Kontrolowana tożsamość środowiska uruchomieniowego |
| Modyfikuj użytkowników lub politykę SSH | Nie | Oddzielna administracja |
| Zmień konfigurację workflow | Nie dla tożsamości środowiska uruchomieniowego | Przegląd chronionego repozytorium |
| Usuń kopie zapasowe | Nie | Oddzielne uprawnienia odzyskiwania |
Waliduj dane wejściowe akcji wydania. Ograniczone polecenie, które łączy dowolny tekst w uprzywilejowanej powłoce, nadal pozwala na niezamierzone działania. Przejrzyj razem zachowanie wrappera, ścieżki zapisywalne i zaufanie do artefaktu. Szerokie uprawnienia sudo lub dostęp do gniazda Docker mogą znieść zamierzoną granicę.
Traktuj edycje workflow jako dostęp do poświadczeń
Osoba mogąca zmieniać zaufane kroki workflow może użyć lub ujawnić swoje poświadczenia. Przejrzyj uprawnienia repozytorium, chronione środowiska wdrożeniowe i zdarzenia uruchamiające uprzywilejowane zadania. Trzymaj produkcyjne poświadczenia z dala od niezaufanego kodu pull requestów. Dawaj tokenowi workflow tylko uprawnienia potrzebne jego zadaniu.
GitHub zaleca przypinanie pełnego SHA commita do niezmiennego wyboru akcji. Przejrzyj wybraną akcję i późniejsze aktualizacje; tag wersji może się przesunąć. Unikaj wstawiania niezaufanych danych zdarzeń bezpośrednio do wbudowanego kodu powłoki. Maskowanie znanych wartości sekretów nie gwarantuje ochrony przed ujawnieniem przez transformacje, logi lub artefakty.
Dokumentacja techniczna: Bezpieczne użycie GitHub Actions.
Używaj krótkiego czasu życia, gdy miejsce docelowe to obsługuje
OpenID Connect może pozwolić obsługiwanemu miejscu docelowemu wymienić tożsamość workflow na krótkotrwałe poświadczenie. Skonfiguruj kontrole zaufania dla zamierzonego repozytorium, gałęzi lub środowiska i odbiorcy. To nie jest uniwersalny zamiennik SSH ani funkcja dostarczana przez obecny frontend PrivacyNodes.
Jeśli Twoje wdrożenie używa SSH, przejrzyj opcje autoryzowanych kluczy w zainstalowanym pakiecie. Samo wymuszone polecenie nie zabrania przekazywania; ograniczenia muszą obejmować zamierzone ścieżki dostępu i nadal wywoływać bezpieczną operację wydania. Przetestuj w osobnym środowisku. Zachowaj działającą administrację i dostęp do odzyskiwania podczas zmiany uwierzytelniania oraz zweryfikuj świeże niezależne połączenie przed usunięciem starej metody.
Dokumentacja techniczna: GitHub Actions OpenID Connect · format OpenSSH authorized_keys.
Przetestuj dozwolone i zabronione prace
Zweryfikuj, że tożsamość może wybrać zamierzony artefakt, wywołać wydanie i uzyskać użyteczny wynik. Następnie przetestuj jej ograniczenia: sekrety innej aplikacji, niezwiązane zmiany plików i dowolna administracja powinny być niedostępne. Uwzględnij ścieżki artefaktów i argumenty, które wrapper musi odrzucić.
Zapisz tożsamość, zakres, datę wygaśnięcia, jeśli dotyczy, zatwierdzającego opiekuna i lokalizację dowodów audytu. Przechowuj odwołania do magazynu, a nie wartości poświadczeń. Jeśli test działa tylko po przyznaniu szerokiej administracji, wróć do zadania wydania, zamiast po cichu czynić to rolą stałą.
Przećwicz unieważnienie i wydanie z uszkodzonym pipeline
Przygotuj zamiennik ze zweryfikowanym zakresem, zweryfikuj wdrożenie testowe, przełącz pipeline i unieważnij starą tożsamość. Potwierdź, że zastąpione poświadczenie zawodzi i nie pozostaje duplikat w innym workflow. Samo dodanie nowego klucza nie usuwa poprzedniego dostępu.
Udokumentuj, jak upoważniony opiekun zatrzymuje wdrożenie i odzyskuje sprawność, gdy CI jest niedostępne. Powiąż tę procedurę z rekordu wydania oraz inwentarzem odzyskiwania. Wąskie poświadczenie ogranicza zamierzone uprawnienia; nie czyni złośliwego artefaktu nieszkodliwym.
Oficjalne odniesienia
Dokumentacja została zweryfikowana dla tego artykułu. Przykłady są ćwiczeniami planistycznymi, a nie poleceniami przetestowanymi na serwerze PrivacyNodes. Sprawdź dokumentację dla swojej zainstalowanej wersji.