Przejdź do treści
Wczesny dostępZaszyfrowany sejf, Kontrola dostępu i CI/CD

Zabierz pliki .env z czatu zespołu

W młodym zespole sekrety leżą tam, gdzie trafiły najpierw: w przypiętej wiadomości, we wspólnej notatce, na czyimś laptopie. Crunu daje im jedno miejsce, szyfrowane na urządzeniu każdej osoby, z dostępem dopasowanym do pracy. Działa na app.crunu.com, więc nie trzeba stawiać serwera.

Dla kogoZałożyciele i pierwsi inżynierowie zespołów produktowych liczących od 5 do 50 osób, które dziś wymieniają się plikami .env.

Przykład. Kiteline to fikcyjna firma.

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.

  1. Gdzie powinny leżeć nasze pliki .env zamiast na czacie zespołu?
  2. Jak nowa osoba w zespole dostaje właściwe zmienne pierwszego dnia?
  3. Czy programiści mogą pracować na staging, nie widząc production?
  4. Kto zmienił tę wartość i jaka była wcześniej?
  5. Jak dać CI zmienne staging i nic więcej?
  6. Jak production dostaje swoje sekrety bez przechodzenia przez CI?
  7. Co zmieniamy, gdy ktoś odchodzi?
  8. Czy musimy do tego prowadzić serwer?
Lista Getting started prowadzi właściciela nowej organizacji przez pierwsze pięć kroków.

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.

  • Zaszyfrowany sejf

    Przechowuj pliki .env, dane dostępowe do chmury i klucze API w projektach i środowiskach, szyfrowane na twoich urządzeniach, zanim cokolwiek trafi na serwer.

    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

  • 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

  • Maszyny

    Zarejestruj serwer jednorazowym kodem, a agent crunu trzyma jego środowiska w pamięci i uruchamia z nimi twoje programy.

    Dowiedz się więcej

  • Offboarding

    Gdy ktoś odchodzi, serwer przestaje wydawać tej osobie dane, klucze jej środowisk się zmieniają, a raport pokazuje, co widziała i co wygenerować ponownie.

    Dowiedz się więcej

startupy: jak to działa

Na tej stronie

Czego rosnący zespół potrzebuje od swoich sekretów

Gdy produkt buduje pięć osób, każda ma każdy klucz. Przy piętnastu nowa osoba czeka, aż ktoś wklei właściwy plik, staging i production po cichu się rozjeżdżają, a nikt nie wie na pewno, kto jeszcze zna hasło do produkcyjnej bazy danych.

Zadanie łatwo opisać: jedna kopia każdej wartości, odczytywana tylko przez osoby i maszyny, które jej potrzebują, i czyste wyjście, gdy ktoś odchodzi.

Od pierwszego zatrudnienia do pierwszego pytania audytora

PotrzebaCo robi Crunu
Jedno miejsce na każdy .envProjekty zawierają środowiska, takie jak development, staging i production. Przeciągnij pliki .env albo całe foldery; pliki env, INI i płaski YAML edytuje się pole po polu.
Nowe osoby mają właściwy dostęp od pierwszego dniaZaproś kogoś linkiem ważnym do 7 dni, zweryfikuj odcisk klucza i nadaj profil dostępu, na przykład Developers: Editor w development i staging.
Programiści nie odczytają productionKażde środowisko ma własny klucz. Osoba z dostępem do development nigdy nie dostaje klucza production.
Mniej wątków „która wartość jest właściwa?”Każde środowisko przechowuje ostatnie 100 wersji z autorem, czasem i nazwami zmienionych pól. Porównaj staging z production i skopiuj wybrane wartości.
CI, które widzi staging i nic więcejToken usługowy dostaje tylko środowiska, do których dasz mu dostęp. Powiązanie CI (OIDC) wiąże go z jednym repozytorium i gałęzią.
Production, które zostaje na produkcjiSerwer produkcyjny uruchamia agenta crunu i sam pobiera swoje środowisko. Potok tylko restartuje usługę.
Czyste wyjścieUsunięcie członka zespołu wymienia klucze każdego środowiska, które ta osoba mogła odczytać, pokazuje, co otrzymała, i wymienia wartości do ponownego wygenerowania u dostawców.

Tydzień od rozrzuconych plików do jednego sejfu

  1. Utwórz organizację. Zarejestruj się adresem e-mail. Hasło i Secret Key powstają w przeglądarce, a ty zapisujesz swój Emergency Kit.
  2. Dodaj jeden projekt na aplikację. Nadaj mu środowiska, których używasz, i przeciągnij pliki, które już masz.
  3. Zaproś zespół. Grupuj dostęp w profilach dostępu, żeby zmiana w Developers docierała do wszystkich w tym profilu.
  4. Podłącz CI. Utwórz token usługowy dla staging i wklej do potoku kroki instalacji, które pokazuje aplikacja.
  5. Dokończ listę kontrolną. Lista Getting started w aplikacji prowadzi właściciela nowej organizacji przez projekt, zmienne, członka zespołu, maszynę i drugi składnik.

Co warto wiedzieć przed przeprowadzką

  • Dostęp osób nie ma daty końcowej. Usuń osobę, gdy jej praca się skończy. Zaproszenia, linki dostępu, tokeny usługowe i dzierżawy maszyn wygasają.
  • Brak logowania jednokrotnego (SSO) i SCIM. Członkowie zespołu logują się hasłem, Secret Key i drugim składnikiem.
  • Właściciele i administratorzy mają dostęp do każdego wspólnego środowiska przez klucz odzyskiwania organizacji. Dawaj te role osobom, które prowadzą organizację.
  • Tego, co ktoś już zobaczył, nie da się odebrać. Rotacja chroni nowe wersje; same wartości generuje się ponownie u każdego dostawcy.
  • Serwer nie zresetuje hasła. Jeśli każdy właściciel i administrator straci hasło, Secret Key i kod odzyskiwania, nikt nie będzie mógł zarządzać organizacją. Niech organizacja ma dwóch właścicieli, a każdy z nich zachowa swój Emergency Kit.

Każde ograniczenie wraz z tym, co z nim zrobić, opisuje strona ograniczeń.

Bezpłatnie we wczesnym dostępie

Wszystkie funkcje są dostępne w ramach limitów wymienionych na stronie cennika. Nie ma etapu płatności.

Powiązana dokumentacja i integracje

Odpowiedzi na pytania

Nie ma tu odpowiedzi? Napisz na support@crunu.com, a odpowie ci człowiek.

Czy to naprawdę jest bezpłatne?

Tak, we wczesnym dostępie. Wszystkie funkcje są dostępne i nie ma etapu płatności.

Czy musimy prowadzić serwer?

Nie. Zarejestruj się na crunu.com, a twoja organizacja działa na app.crunu.com. Ten sam serwer może też działać na twojej własnej infrastrukturze: Docker, Cloudflare Workers, Vercel lub Google Cloud Run. Serwer nie jest publikowany do publicznego pobrania. Napisz na support@crunu.com.

Czy programista z dostępem do staging odczyta production?

Nie. Każde środowisko ma własny klucz, a klucz production jest zaszyfrowany tylko dla osób i maszyn, którym dasz dostęp do production.

Co, jeśli ktoś zapomni hasła?

Serwer nie może go zresetować, bo nigdy go nie miał. Jeśli ta osoba utworzyła kod odzyskiwania, odzyska dostęp po okresie oczekiwania, a jej konto dostaje w tym czasie powiadomienie. Jeśli ktoś z zespołu straci zarówno hasło, jak i Secret Key, administrator może przenieść osobiste środowiska tej osoby na nowe konto.

Jak bardzo możemy z tym urosnąć?

Organizacja mieści do 500 projektów, projekt do 50 środowisk, a jedno środowisko do 1 MB treści i listę dostępu do 5000 wpisów.

Czy możemy zabrać swoje dane?

Tak. Wyeksportuj środowisko jako pojedynczy plik .env, jako plik chroniony hasłem albo do Ansible Vault lub pobierz kopię offline wszystkiego, co możesz odczytać. Kopia offline otwiera się twoim hasłem i Secret Key, bez serwera. Środowiska ograniczone regułą sieciową nie są w niej uwzględniane.

Czy Crunu obsługuje SSO?

Nie. Nie ma logowania osób przez SAML ani OIDC ani synchronizacji z katalogiem.

Przenieś jeden projekt przed kolejnym zatrudnieniem

Utwórz organizację, przeciągnij jeden plik .env i zaproś jedną osobę z zespołu. Bezpłatnie we wczesnym dostępie.