Ekran „Pliki" pozwala wgrywać bazy, archiwizować je i (dla administratora)
kasować, a stan użycia jest klikany, więc musi przetrwać restart poda. Warstwa
danych musi zatem móc pisać na udziale — dotąd był montowany read-only.
ŚWIADOMY KOSZT: znika jedna warstwa obrony w głąb. Przejęcie warstwy danych
pozwala teraz nie tylko odczytać bazy, ale i je zmienić. Zostaje reszta: token
międzywarstwowy, szyfrowane łącze, ograniczenie eksportu NFS do konkretnych
hostów (DAN-25) oraz to, że kasować może wyłącznie konto administracyjne (PRE-27).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Wszystkie cztery usługi biegły na koncie `default` z AUTOMATYCZNIE montowanym
tokenem API Kubernetesa. Żadna z nich nie rozmawia z API klastra — sekrety dostają
przez `secretKeyRef`, który wstrzykuje kubelet, nie pod. Token był więc zbędny,
a leżał w każdym kontenerze jako gotowy punkt wyjścia do klastra dla kogoś, kto
przejmie proces (np. przez lukę w zależności).
`automountServiceAccountToken: false` w szablonie poda data/logic/presentation/
render. Zweryfikowane `kubectl kustomize` — pole trafia do `.spec.template.spec`,
nie do specu Deploymentu (tam byłoby ciche i bez efektu).
Zero wpływu na działanie: nic w kodzie nie woła API Kubernetesa.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Domyka PRE-16 po stronie manifestow. Kod (astrololo#21) potrafi juz szyfrowac
ruch miedzy warstwami AES-256-GCM; tu dokladamy klucze i wymuszenie.
- astrololo-link: nowy sekret z dwoma kluczami (LINK_KEY_PRESENTATION_LOGIC,
LINK_KEY_LOGIC_DATA), tworzony POZA repo jak pozostale. Osobny klucz na pare
rozmowcow: przejecie klucza prezentacji nie otwiera warstwy danych. Logika
bierze oba, prezentacja i dane wylacznie swoj (secretKeyRef).
- LINK_ENCRYPTION_REQUIRED=true we wszystkich trzech: bez klucza pod NIE wstaje,
a klient nie wysyla niczego. Fail-closed w obie strony jest celowy — usluga,
ktora wstala i po cichu nie szyfruje, jest gorsza niz CrashLoop, bo awarii
nie widac.
README: sekcja o sekrecie astrololo-link (tworzenie, wymiana, restart calej
trojki naraz) oraz uczciwa nota, ze szyfrowane sa ciala, nie naglowki — sciezka
i token jada czytelnie, ale sam token bez klucza nic nie daje.
Sprawdzone: kubectl kustomize + apply --dry-run=server przechodza dla obu
profili. Pelna instrukcja wdrozenia: docs/wdrozenie-pre16.md w repo astrololo.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Domyka od strony wdrozenia ochrone dodana w aplikacji (PR #10 w repo astrololo).
Bez tych zmiennych aplikacja startuje OTWARTA, a wystawia tresc oryginalnych
baz interpretacyjnych.
- presentation: APP_PASSWORD + INTERNAL_TOKEN z sekretu, APP_USER i
RATE_LIMIT_PER_MIN jawnie (nie sa tajne).
- logic, data: INTERNAL_TOKEN z sekretu — bez niego da sie ominac logowanie,
uderzajac wprost w warstwe nizej. Warstwa danych oddaje SUROWE wiersze,
wiec to najwrazliwszy punkt.
WARTOSCI SEKRETOW CELOWO NIE TRAFIAJA DO REPO — to GitOps, wiec zostalyby
w historii gita na zawsze i przekreslily caly sens tej zmiany. Manifesty
tylko odwoluja sie do sekretu `astrololo-auth`, tworzonego poza repo — ta sama
konwencja co istniejacy `gitea-registry`.
UWAGA: sekret jest WYMAGANY (bez `optional: true`), wiec pody nie wstana,
dopoki go nie utworzysz. To swiadome: lepsza widoczna awaria niz cichy start
bez ochrony. Instrukcja tworzenia i zmiany hasla w astrololo/README.md.
Przy okazji: poprawiony mylacy komentarz przy EXCEL_DIR — pliki baz ida
z NFS, nie z obrazu (montaz je nadpisuje).
Zwalidowane `kubectl kustomize` dla bazy i profilu swisseph: sekrety trafiaja
do wlasciwych uslug, a w wyniku nie ma zadnego `kind: Secret`.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
gitea