Sekrety trafiają na serwery, które ich używają, a nie do potoku po drodze
Agent crunu działa na twoich serwerach z Linuksem, trzyma odszyfrowane środowiska w pamięci i uruchamia z nimi twoje programy. CI dostaje token do środowiska, które buduje, powiązany z jednym repozytorium i gałęzią. Wartości production w ogóle nie muszą przechodzić przez CI.
Pytania, które zadają zespoły takie jak twój
Pytania, które pojawiają się, gdy zespół taki jak twój przenosi sekrety w jedno miejsce. Poniższy przewodnik odpowiada na każde z nich.
- Jak serwer dostaje swoje środowisko bez pliku na dysku?
- Jak trzymać wartości production z dala od CI?
- Jak powiązać token CI z jednym repozytorium i gałęzią?
- Co dzieje się z działającymi usługami, gdy sejf jest nieosiągalny?
- Jak szybko działa odebranie dostępu maszynie?
- Czy możemy wydawać production tylko naszym własnym sieciom?
- Kto może rejestrować maszyny, nie widząc wartości?
- Jak skrypt wdrożeniowy może rozpoznać, dlaczego crunu zakończył się błędem?
Części Crunu, które to obejmują
Każda część działa według tej samej zasady: serwer przechowuje zaszyfrowane dane, klucze publiczne i podpisane dokumenty i nigdy nie ma klucza, który otwiera twoje wartości.
Maszyny
Zarejestruj serwer jednorazowym kodem, a agent crunu trzyma jego środowiska w pamięci i uruchamia z nimi twoje programy.
Dowiedz się więcej
CI/CD
Daj każdemu potokowi token usługowy ograniczony do jego środowisk i powiąż go z dostawcą CI przez OIDC, żeby wyciekły token nie mógł sam się zalogować.
Dowiedz się więcej
Reguły sieciowe
Wydawaj zawartość środowiska tylko dozwolonym sieciom IPv4 i IPv6, z podpisanymi regułami, których nie da się po cichu złagodzić.
Dowiedz się więcej
Dziennik audytu
Logowania, nadania dostępu, wersje, rotacje i odmowy trafiają do dziennika w łańcuchu skrótów, który możesz zweryfikować jednym kliknięciem i wyeksportować.
Dowiedz się więcej
Kontrola dostępu
Daj każdej osobie, maszynie i potokowi tylko te środowiska, których potrzebuje, z rolami opartymi na kluczach szyfrowania, a nie tylko na kontrolach po stronie serwera.
Dowiedz się więcej
zespoły platformowe: jak to działa
Na tej stronie
Gdzie sekrety wyciekają w drodze do procesu
Przekazanie wartości do działającego procesu to moment, w którym zwykle ucieka: plik .env wbudowany w obraz, klucz production zapisany w zmiennych CI, użytkownik wdrożeniowy, który może odczytać wszystko.
Zadanie polega na tym, żeby każda maszyna i każdy potok dostawały dokładnie swoje środowiska, żeby nic nie lądowało na dysku, chyba że tak zdecydujesz, i żeby odebranie dostępu było jedną czynnością.
Cztery kroki od nowego serwera do działającej usługi
- Utwórz maszynę. Wybierz jej środowiska i sposób dostarczania: klucz środowiska (Environment key), który zawsze daje najnowszą wersję każdego pliku, albo wybrane pliki (Selected files), czyli zaszyfrowaną kopię tylko tych plików, których maszyna potrzebuje. Wybrane pliki można odebrać bez zmiany klucza środowiska.
- Zainstaluj i zarejestruj. Okno Enroll machine pokazuje jedno polecenie, które instaluje agenta, sprawdza jego SHA-256 i rejestruje maszynę jednorazowym kodem. Kod jest domyślnie ważny 15 minut, najwyżej 24 godziny, i jest odczytywany ze stdin lub zmiennej, nigdy z argumentu.
- Zatwierdź po odcisku klucza.
crunu enrollwypisuje odcisk klucza maszyny. Zatwierdź maszynę, gdy sprawdzisz, że zgadza się z odciskiem w aplikacji. - Uruchamiaj usługę przez agenta. Użytkownik usługi musi należeć do grupy
crunu. Z--restart on-changeprogram uruchamia się ponownie z nowymi wartościami po ich zmianie.
# /etc/systemd/system/payments-api.service
[Service]
User=payments
ExecStart=/usr/local/bin/crunu run --env payments-api/production --restart on-change -- /opt/payments-api/bin/serverCo robią za ciebie agent i tokeny
| Potrzeba | Co robi Crunu |
|---|---|
| Bez sekretów na dysku | Usługa agenta trzyma odszyfrowane środowiska tylko w pamięci i przekazuje je crunu run przez lokalne gniazdo dostępne dla grupy crunu. Zobacz systemd. |
| Pliki tam, gdzie oczekuje ich narzędzie | crunu pull zapisuje pliki z uprawnieniami 0600 w dwóch fazach, zachowuje poprzednią wersję jako .prev, nie podąża za dowiązaniami symbolicznymi i odmawia zapisu plików startowych powłoki, .ssh/ i katalogów systemd. --env-out zapisuje jeden plik env dla EnvironmentFile=. |
| Agent, którego możesz sprawdzić | Statyczny plik binarny w Go, korzystający tylko z biblioteki standardowej. Na Linuksie jest odizolowany od innych procesów tego samego użytkownika, zrzuty pamięci są wyłączone, a usługa działa w piaskownicy systemd. Aktualizacje sprawdzają podpis Ed25519. |
| Serwery, które przetrwają awarię | Agent sprawdza serwer co minutę i odnawia dzierżawę co 5 minut. Jeśli serwer jest nieosiągalny, wydaje ostatni zweryfikowany stan do końca dzierżawy, domyślnie przez 24 godziny. |
| CI bez production | Tokeny usługowe dostają tylko środowiska, do których dasz im dostęp, z dzierżawą, limitem użyć i sieciami. Powiązanie CI (OIDC) wiąże token z repozytorium, gałęzią i środowiskiem wdrożenia w GitHub Actions, GitLab CI, Bitbucket Pipelines lub u dowolnego wydawcy OIDC. Ponownie użyty token CI jest odrzucany. |
| Production tylko ze znanych sieci | Podpisane listy sieci i reguły sieciowe środowisk dla IPv4 i IPv6. Zaostrzenie działa od razu; złagodzenie czeka 15 minut z alertem i możliwością cofnięcia albo działa od razu z drugim podpisem. Przepustki maszyn obejmują zmiany adresów, domyślnie przez 24 godziny. |
| Odebranie dostępu jedną czynnością | Odebranie dostępu maszynie usuwa jej środowiska z pamięci w ciągu kilku minut, gdy maszyna jest online, i wymienia klucze środowisk, które miała. Ponownie użyty kod rejestracji sygnalizuje możliwe przechwycenie. |
| Sygnały | Alerty o logowaniach z nowych urządzeń, ponownie użytych kodach rejestracji, maszynach pod nowymi adresami, ponownie użytych tokenach CI, wygasłych dzierżawach i zdarzeniach sieciowych, wysyłane do webhooka podpisanego HMAC lub e-mailem. Slack, Microsoft Teams i PagerDuty łączą się przez swoje przychodzące webhooki. |
Błędy, które da się odróżnić
Gdy crunu nie może przekazać zmiennych, jego kod wyjścia mówi dlaczego, więc skrypt wdrożeniowy może zareagować. W pozostałych przypadkach crunu run zwraca kod wyjścia twojego programu.
| Kod | Znaczenie |
|---|---|
3 | Maszyna nie jest zarejestrowana albo nikt nie jest zalogowany |
4 | Dostęp został odebrany albo dzierżawa wygasła |
5 | Brak połączenia i brak ważnego zweryfikowanego stanu |
6 | Kontrola podpisu lub certyfikatu nie powiodła się |
7 | Reguła sieciowa środowiska nie dopuszcza tego adresu |
Gdzie kończy się agent
- Usługa działa na Linuksie z systemd. Na macOS
crunudziała jako narzędzie wiersza poleceń, bez usługi w tle. Nie ma wersji na Windows. - Nie ma operatora Kubernetes, chartu Helm ani sterownika CSI, dostawcy Terraform ani SDK. Programy dostają wartości przez
crunu run. - Nie ma wbudowanej synchronizacji z Vercel, Cloudflare, AWS Secrets Manager ani GitHub Secrets. Możesz przesyłać wartości z CI przez
crunu runi własne CLI platformy. - Nie ma dynamicznych sekretów. Crunu nie generuje krótkotrwałych haseł do baz danych; wymagałoby to klucza na serwerze.
- Maszyna jest uprawnionym odbiorcą. Root na niej może odczytać to, co otrzymała, a działający proces zachowuje swoje zmienne do ponownego uruchomienia.
- Ograniczenia sieciowe egzekwuje serwer, nie szyfrowanie. Przejęty serwer by ich nie przestrzegał, a wszystkie maszyny za jednym NAT mają ten sam adres.
Każde ograniczenie wraz z tym, co z nim zrobić, opisuje strona ograniczeń.
Jeśli prowadzisz też serwer
Zespoły, które chcą mieć serwer u siebie, mogą uruchomić go na Dockerze, Cloudflare Workers, Vercel lub Google Cloud Run i przenosić między nimi jednym archiwum, które nie zawiera jawnych wartości. Polecenie doctor sprawdza wdrożenie, a punkt końcowy statusu udostępnia metryki w formacie Prometheus. Serwer nie jest publikowany do publicznego pobrania. Napisz na support@crunu.com. Strona o własnym hostingu porównuje platformy.
Powiązana dokumentacja i integracje
- Instalacja agenta na serwerze
- Maszyny i dzierżawy
- crunu run
- crunu pull
- Rejestracja maszyny i uruchomienie usługi
- Zmienne środowiskowe i kody wyjścia
- Powiązanie tokenu usługowego z CI przez OIDC
- Ogranicz production do sieci biura
- Własny hosting: przegląd i platformy
- systemd
- Docker
- GitHub Actions
- GitLab CI
- Bitbucket Pipelines
Odpowiedzi na pytania
Nie ma tu odpowiedzi? Napisz na support@crunu.com, a odpowie ci człowiek.
Co dzieje się z działającymi usługami, gdy Crunu jest nieosiągalne?
Działają dalej. Agent wydaje ostatni zweryfikowany stan do końca dzierżawy, domyślnie przez 24 godziny. Jeśli nie ma ważnego stanu, crunu run kończy się kodem 5.
Jak szybko działa odebranie dostępu maszynie?
W ciągu kilku minut, gdy maszyna jest online: agent sprawdza serwer co minutę i usuwa jej środowiska, gdy dostęp zostanie odebrany. Maszyna, która pozostaje offline, traci dostęp z końcem dzierżawy.
Czy CI może wdrażać na production, nie widząc sekretów production?
Tak, i to konfiguracja, którą zaleca Crunu. Serwer produkcyjny uruchamia agenta i sam pobiera swoje środowisko; potok dostarcza kod i restartuje usługę.
Czy crunu działa w kontenerach?
Skrypt instalacyjny ma tryb bez roota przeznaczony dla CI i kontenerów, testowany w obrazach node:24, Ubuntu 24.04 i Alpine 3.22. Z tokenem usługowym crunu loguje się i odszyfrowuje wewnątrz własnego procesu, bez plików stanu.
Czy ktoś może rejestrować maszyny, nie widząc żadnych wartości?
Tak. Rola Operator w środowisku nie ma klucza: dodaje maszyny i prosi o dostęp dla nich, a właściciel lub administrator go zatwierdza.
Czy obsługujecie Kubernetesa?
Nie. Nie ma operatora, chartu Helm ani sterownika CSI.