Państwa infrastruktura. Państwa dane. Państwa klucze.
Cronable jest zbudowany tak, aby działać jak zaufana część Państwa własnego stosu. Oto dokładnie, jak utrzymuje Państwa automatyzację, sekrety i historię pod Państwa kontrolą.
On-premises z założenia
Cronable instaluje się na Państwa własnej maszynie — jako aplikacja desktopowa na Maca lub Windows albo jako serwer pod systemd/launchd. Nie ma warstwy SaaS ani zależności od chmury. Jego rutynowe połączenia wychodzące to okresowe sprawdzenie licencji — które potwierdza Państwa subskrypcję i raportuje proste liczby zadań i użytkowników — oraz sprawdzanie nowych podpisanych wydań; a także, tylko jeśli je Państwo włączą, wychodzące połączenie z hostowanym relay Cronable dla przychodzących webhooków lub zdalnego sterowania. Państwa praca — definicje zadań, sekrety, uruchomienia i wyniki — pozostaje na maszynie i nigdy nie jest do nas wysyłana. Jedynym wyjątkiem jest aktywna sesja zdalnego sterowania: jej ruch z konsoli jest przekazywany przez nasz brzeg sieci (takie samo zaufanie jak każdy hostowany serwer proxy), a szyfrowanie end-to-end do Państwa własnej maszyny to planowana opcja w planie Enterprise.
Sekrety i poświadczenia szyfrowane w spoczynku
Wartości sekretów są szyfrowane algorytmem AES-256-GCM kluczem wyprowadzonym z Państwa własnego klucza szyfrującego (scrypt z losową solą na instalację). Typowane poświadczenia — klucze API, tokeny bearer, uwierzytelnianie podstawowe, niestandardowe nagłówki i ciągi połączenia z Postgres — żyją w tym samym zaszyfrowanym magazynie i są przywoływane po nazwie, nigdy wklejane do plików zadań. Nic nie jest zapisywane do git i nic nie opuszcza Państwa maszyny. Klucz tworzą Państwo kopię osobno — jeśli go stracicie, sekrety są z założenia nieodzyskiwalne.
Maskowane w każdym logu i strumieniu
Rozwiązane wartości sekretów i poświadczeń są redagowane do „***” w plikach logów, wyniku zadań i strumieniu logów na żywo — nawet gdy wartość jest rozbita między fragmentami strumienia. To, co działa na Państwa maszynie, zostaje na Państwa maszynie.
Uwierzytelnianie i najmniejsze uprawnienia
Konsola webowa wymaga logowania per użytkownik z haszowaniem haseł argon2id i blokadą przy atakach siłowych. Silnik domyślnie nasłuchuje na localhost i jest przeznaczony do działania jako dedykowany użytkownik o niskich uprawnieniach. Wywołania serwer-serwer używają prywatnego tokenu bearer; przeglądarki używają krótkotrwałego ciasteczka sesji — a wylogowanie lub wygaśnięcie sesji zamyka nawet otwarte strumienie logów na żywo w ciągu kilku sekund. Hasła muszą też przejść kontrolę siły — minimalną długość oraz test odgadywalności — dzięki czemu słabe lub łatwe do odgadnięcia są odrzucane. Opcjonalne uwierzytelnianie dwuskładnikowe (TOTP) dodaje jednorazowy kod z aplikacji uwierzytelniającej, takiej jak Google Authenticator, wraz z kodami odzyskiwania na wypadek utraty urządzenia; jest wymagane do korzystania z dostępu zdalnego, więc maszynę można otworzyć w hostowanym panelu tylko przez osobę, która je włączyła.
Dostęp zespołu oparty na rolach
Konsola webowa jest wieloużytkownikowa i ma cztery uporządkowane role — przeglądający (tylko do odczytu), edytor (tworzy zadania, sekrety i uruchomienia), administrator (zarządza użytkownikami, rolami i ustawieniami) oraz właściciel, czyli pierwsze konto instalacji. Administratorzy dodają i usuwają użytkowników, ustawiają rolę każdej osoby, resetują hasło lub urządzenie dwuskładnikowe i cofają dostęp w sekcji Ustawienia → Użytkownicy — dzięki czemu odchodzący członek zespołu traci dostęp natychmiast i nikt nie współdzieli loginu. Instalacje o zaostrzonych regułach mogą włączyć więcej: warstwowanie uprawnień wykonawczych ogranicza, kto może tworzyć zadania uruchamiające polecenia, a zatwierdzanie zmian dodaje kontrolę według zasady dwóch par oczu — drugi administrator musi zatwierdzić oczekującą zmianę zadania lub sekretu, zanim zacznie ona obowiązywać.
Logowanie jednokrotne przez OIDC
Wnieś swojego dostawcę tożsamości — Okta, Entra ID, Google, Keycloak — przez przepływ authorization-code OIDC z PKCE i pełną weryfikacją tokenu ID. Logowania SSO muszą odwzorowywać się na istniejące konto lokalne: nic nie jest udostępniane automatycznie, a błędy dostawcy pojawiają się jako stałe, przyjazne komunikaty, a nie surowe przekierowania.
Ścieżka audytu, którą naprawdę da się czytać
Logowania i nieudane próby, zmiany sekretów i poświadczeń, edycje zadań, aktualizacje ustawień i synchronizacje git są zapisywane w ścieżce audytu tylko do dopisywania — wyłącznie nazwy i metadane, nigdy wartości — do podglądu i filtrowania wprost w konsoli w sekcji Ustawienia → Audyt.
Wzmocnione przychodzące webhooki
Przychodzące webhooki docierają do Państwa daemona przez naszą, chronioną licencją, przekaźnię, po połączeniu, które Państwa serwer otwiera na zewnątrz, więc nigdy nie odsłaniają Państwo portu — chyba że świadomie zdecydują się Państwo to zrobić. Każdy hak jest powiązany z Państwa licencją — żaden inny klient nie może go przejąć ani odbierać jego zdarzeń, nawet znając jego URL — i chroniony tokenem per hak, przechowywanym wyłącznie jako hasz SHA-256 i sprawdzanym w stałym czasie. URL wymaga co najmniej 32 nieodgadywalnych znaków plus tego tokenu; błędny, brakujący, wyłączony lub nieznany — wszystkie zwracają ten sam ogólny 401, a powtarzane próby z danego IP są tymczasowo blokowane — więc nie ma czego wyliczać ani łamać siłowo. Tokeny są ujawniane raz przy utworzeniu i rotowalne jednym kliknięciem. Jeśli wolą Państwo, aby przychodzące dane w ogóle nie przechodziły przez nasze serwery, mogą Państwo pominąć przekaźnię i udostępnić własny punkt końcowy HTTPS — to jedyny przypadek, w którym rzeczywiście otwierają Państwo port, a webhooki trafiają wtedy prosto na Państwa maszynę.
Historia audytowana w git, odwracalna
Każda definicja zadania to plik w repozytorium git, które należy do Państwa. Każda zmiana to commit — w pełni porównywalny, przypisywalny i odwracalny. Historia Państwa zadań jest audytowalna narzędziami, których Państwa zespół już używa. Gdy łączysz repozytorium do synchronizacji dwukierunkowej, Cronable akceptuje tylko prywatne — odrzuca repozytorium publiczne i wstrzymuje synchronizację, jeśli połączone repozytorium zostanie później upublicznione — dzięki czemu Twoje definicje zadań nigdy nie staną się publicznie dostępne.
Uczciwie o granicy zaufania
Zadaniem Cronable jest uruchamianie poleceń, agentów AI i HTTP w Państwa imieniu, więc traktujcie go jak powłokę na maszynie. Wyrażenia działają w piaskownicy chroniącej przed strzałami we własną stopę, a nie na wzmocnionej granicy — nigdy nie podawajcie mu niezaufanych danych. Pomożemy Państwu wdrożyć go z najmniejszymi uprawnieniami i rozsądną izolacją sieci.
Uruchom to za swoją zaporą sieciową.
Mają Państwo wymagania bezpieczeństwa do spełnienia? Opiszcie nam swoje środowisko, a wspólnie przejdziemy przez wdrożenie, hartowanie i kontrolę dostępu.
Cronable — i nigdy nie opuszcza Państwa maszyny.