Vaulted
Zaktualizowano

Udostępnianie sekretów w GitHub Actions – bez Vaulta

Autor:

Możesz udostępniać sekrety w GitHub Actions bez HashiCorp Vault, używając akcji GitHub od Vaulted. Tworzy ona zaszyfrowane, samozniszczące się linki bez żadnej infrastruktury. Korzysta z szyfrowania po stronie klienta AES-256-GCM i działa jako pojedynczy krok workflow — bez serwera menedżera sekretów ani konfiguracji w chmurze.

Potoki CI przez cały czas potrzebują tymczasowych danych uwierzytelniających. Klucz deploy, który powinien istnieć tylko przez jeden run. Token przekazywany między dwoma repozytoriami podczas migracji. Dane uwierzytelniające rotowane w jednym workflow i konsumowane w innym.

Standardowa rada brzmi: „użyj menedżera sekretów." Ale uruchamianie HashiCorp Vault lub konfigurowanie AWS Secrets Manager tylko po to, by przekazać jedne dane uwierzytelniające między workflow, to jak wynajmowanie magazynu, żeby wysłać list.

GitHub Repo Secrets dobrze radzą sobie ze statycznym przypadkiem — długotrwałe klucze API, tokeny deploy, dane uwierzytelniające konta serwisowego. Ale nie wystarczają dla czegokolwiek tymczasowego lub dynamicznego.

Luka: tymczasowe udostępnianie sekretów w CI/CD

Repo Secrets są zaprojektowane dla wartości, które rzadko się zmieniają i są konsumowane przez jedno repozytorium. Nie obejmują:

  • Jednorazowych przekazań podczas rotacji kluczy — Rotujesz dane uwierzytelniające w jednym workflow i inny workflow (lub zespół) musi pobrać nową wartość dokładnie raz.
  • Udostępniania danych uwierzytelniających między repozytoriami — Dwa repozytoria muszą wymienić krótkotrwały token, ale żadne nie powinno go trwale przechowywać.
  • Czasowo ograniczonego dostępu dla podwykonawców — Token CI, który powinien wygasnąć po zamknięciu okna deploymentu podwykonawcy.
  • Wiedzy o tym, kiedy sekret został odczytany — Repo Secrets nie dają żadnego wglądu w to, czy i kiedy wartość została przeczytana.

To są tymczasowe problemy, które wymagają tymczasowego rozwiązania.

Lżejsze podejście: zaszyfrowane, samozniszczające się linki

Akcja Vaulted na GitHub pozwala tworzyć i pobierać zaszyfrowane, samozniszczające się sekrety bezpośrednio z twoich workflow — bez żadnej infrastruktury do zarządzania.

Tworzenie sekretu:

- name: Share rotated credential
  id: share
  uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ steps.rotate.outputs.new_token }}
    views: 1
    expires: 1h

Krok zwraca URL zawierający zaszyfrowany sekret. Klucz szyfrowania znajduje się we fragmencie URL, więc nigdy nie trafia na serwery Vaulted.

Pobieranie sekretu:

- name: Get shared credential
  id: get
  uses: vaulted-fyi/share-secret/get@v1
  with:
    url: ${{ needs.rotate.outputs.secret_url }}

- name: Deploy with rotated credential
  run: ./deploy.sh
  env:
    API_TOKEN: ${{ steps.get.outputs.secret }}

Po pobraniu link jest skonsumowany, a ciphertext po stronie serwera zostaje usunięty. Sekret istnieje tylko w pamięci runnera przez czas trwania tego zadania.

Model bezpieczeństwa

Trzy właściwości sprawiają, że rozwiązanie jest bezpieczne w zastosowaniach CI/CD:

  1. Szyfrowanie zero-knowledge. Sekret jest szyfrowany algorytmem AES-256-GCM wewnątrz runnera GitHub, zanim opuści proces. Klucz szyfrowania jest osadzony w fragmencie URL, który nigdy nie jest wysyłany do serwera. Vaulted przechowuje wyłącznie ciphertext, którego nie może odszyfrować. To jest szyfrowanie po stronie klienta zastosowane do CI/CD.

  2. Automatyczne maskowanie logów. Akcja wywołuje core.setSecret przed core.setOutput, rejestrując każdą linię wartości sekretu w maszerze logów GitHub. Wieloliniowe sekrety są maskowane wiersz po wierszu, więc nawet częściowe dopasowania są redagowane z logów workflow.

  3. Samozniszczające się linki. Limity wyświetleń i wygasanie czasowe są egzekwowane po stronie serwera. Sekret utworzony z views: 1 i expires: 1h zostaje trwale usunięty po pierwszym pobraniu lub po upływie godziny — w zależności od tego, co nastąpi pierwsze.

Kiedy używać tego zamiast menedżera sekretów

ScenariuszMenedżer sekretówVaulted Action
Długotrwałe dane uwierzytelniające produkcyjneTakNie
Konfiguracja runtime aplikacji (URL-e DB, klucze API)TakNie
Jednorazowe przekazanie danych między workflowPrzerost formyTak
Tymczasowe udostępnianie tokenów między repozytoriamiPrzerost formyTak
Czasowo ograniczony dostęp CI dla podwykonawcyPrzerost formyTak
Dystrybucja danych uwierzytelniających po rotacjiPrzerost formyTak

Menedżery sekretów są właściwym narzędziem dla sekretów konsumowanych przez aplikacje w czasie wykonania. Vaulted jest do przekazania — momentu, w którym dane uwierzytelniające przemieszczają się z jednego miejsca do drugiego i nie powinny być trwale przechowywane.

Pierwsze kroki

Dodaj akcję do dowolnego workflow:

- uses: vaulted-fyi/share-secret@v1
  with:
    secret: ${{ secrets.TEMP_CREDENTIAL }}
    views: 1
    expires: 1h

Znajdziesz ją w GitHub Marketplace. Sekrety utworzone przez akcję są kompatybilne z aplikacją webową i CLI — cokolwiek zostało utworzone w jednym miejscu, można pobrać z innego.

Bez serwera Vault. Bez polityk IAM. Bez infrastruktury. Tylko zaszyfrowane linki, które się samozniszczają.

Powiązane