Bezpieczeństwo i uprawnienia

Wdrożenie DAGa z poziomu UI to, z założenia, wysłanie dowolnego kodu do Twojego środowiska Airflow — dokładnie ta sama granica zaufania, co przy każdym innym sposobie dostarczenia pliku .py do katalogu DAGów. DagSmith jest zaprojektowany z uwzględnieniem tego faktu, a nie wbrew niemu.

Deploy jest domyślnie wyłączony

Zapis plików .py jest zablokowany, dopóki administrator nie ustawi deploy_enabled = True. Bez tego DagSmith działa czysto w trybie odczytu i draftów: żaden plik na dysku nigdy się nie zmienia.

Autoryzacja na każdym endpoincie

Każdy endpoint API poza /api/v1/health jest autoryzowany przez Airflow Auth Manager. Zapis draftów wymaga uprawnień do edycji; deploy dodatkowo wymaga roli deployers, ponad globalną flagą deploy_enabled. Jak to zawęża się dalej w ramach katalogów, opisuje Zespoły i deploy przez git.

Izolowane wykonanie

DagSmith nigdy nie uruchamia eval, exec ani dynamicznych importów przez importlib na Twoim źródle DAGa wewnątrz procesu api-servera. Walidacja importu — krok, który faktycznie ładuje Twój DAG tak, jak zrobiłby to scheduler — zawsze dzieje się w osobnym, ograniczonym czasowo podprocesie.

Bezpieczeństwo ścieżek

Każda ścieżka pliku, która przychodzi w requeście, jest rozwiązywana i sprawdzana względem katalogu bundle'a DAGów. Nic poza tym katalogiem nie jest osiągalne, a symlinki, które próbowałyby z niego wyjść, są odrzucane. Zapisy są atomowe (zapis do pliku tymczasowego, potem os.replace) i poprzedzone backupem.

Ślad audytowy

Deploye, git pushe i zmiany przypisania zespołów/plików są zapisywane do dopisywalnego logu JSONL, widocznego w UI dla każdego z uprawnieniami do edycji.