Files

T

gitea 0509ebd597 feat(astrololo): sekrety logowania i tokenu miedzywarstwowego (LOG-32)

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>

2026-07-21 18:53:12 +02:00

3.3 KiB

Raw Permalink Blame History

astrololo — deploy (namespace `astrololo`)

Manifesty k8s składane Kustomize. Obrazy podbija automatycznie image-updater (kustomization.yaml → images: newTag) po każdym buildzie z repo aplikacji.

Warstwy: presentation (NodePort, wejście z przeglądarki) → logic → data (pliki Excel montowane z NFS, nie z obrazu).

⚠️ Sekret `astrololo-auth` — utwórz PRZED wdrożeniem

Aplikacja wystawia treść oryginalnych baz interpretacyjnych, dlatego wymaga logowania i tokenu międzywarstwowego (LOG-32). Manifesty odwołują się do sekretu astrololo-auth i celowo nie zawierają jego wartości — to repo GitOps, więc cokolwiek by tu wpadło, zostałoby w historii gita na zawsze.

To ta sama konwencja co gitea-registry: sekret tworzymy poza repo.

Pody nie wstaną bez tego sekretu — i tak ma być. Wolimy widoczną awarię niż cichy start aplikacji bez ochrony.

# hasło wczytane bez zapisu w historii powłoki
read -rs -p "Hasło do aplikacji (APP_PASSWORD): " APP_PASSWORD; echo

kubectl -n astrololo create secret generic astrololo-auth \
  --from-literal=APP_PASSWORD="$APP_PASSWORD" \
  --from-literal=INTERNAL_TOKEN="$(openssl rand -hex 32)"

unset APP_PASSWORD

INTERNAL_TOKEN jest losowany i nikt go nigdy nie musi oglądać — służy tylko usługom do rozmowy między sobą. APP_PASSWORD wpisujesz w przeglądarce (użytkownik: astrololo, zmienny przez APP_USER w presentation.yaml).

Zmiana hasła

read -rs -p "Nowe hasło: " NEW; echo
kubectl -n astrololo create secret generic astrololo-auth \
  --from-literal=APP_PASSWORD="$NEW" \
  --from-literal=INTERNAL_TOKEN="$(kubectl -n astrololo get secret astrololo-auth \
      -o jsonpath='{.data.INTERNAL_TOKEN}' | base64 -d)" \
  --dry-run=client -o yaml | kubectl apply -f -
kubectl -n astrololo rollout restart deploy/presentation
unset NEW

(Zachowujemy istniejący INTERNAL_TOKEN; jego zmiana wymaga restartu wszystkich trzech usług naraz, inaczej przestaną się dogadywać.)

Sprawdzenie po wdrożeniu

kubectl -n astrololo rollout status deploy/presentation deploy/logic deploy/data
NODE_PORT=$(kubectl -n astrololo get svc presentation -o jsonpath='{.spec.ports[0].nodePort}')
curl -s -o /dev/null -w "bez hasła: %{http_code}\n"  http://<adres-noda>:$NODE_PORT/
curl -s -o /dev/null -w "z hasłem: %{http_code}\n" -u astrololo:'<hasło>' http://<adres-noda>:$NODE_PORT/

Oczekiwane: 401 bez hasła, 200 z hasłem. /health zostaje publiczny (sondy k8s).

Czego to nie załatwia

Brak TLS — Basic Auth idzie po sieci w postaci łatwej do podsłuchania. Przy niezaufanej sieci potrzebny ingress z certyfikatem.
NFS 192.168.1.34:/mnt/Tank1/astrololo — kto ma dostęp do share'u, bierze pliki baz z pominięciem całej aplikacji. Do zamknięcia po stronie infrastruktury (eksport tylko dla IP węzłów, root_squash, najlepiej read-only).
Sekret w etcd jest tylko zakodowany base64. Docelowo: szyfrowanie etcd at-rest albo Sealed Secrets / SOPS, jeśli chcecie trzymać sekrety deklaratywnie w repo.

Profil ze swissephem

Wariant z silnikiem B: ../astrololo-swisseph/. Dziedziczy powyższe zmienne z tej bazy, więc też wymaga sekretu astrololo-auth.

3.3 KiB Raw Permalink Blame History

astrololo — deploy (namespace astrololo)

⚠️ Sekret astrololo-auth — utwórz PRZED wdrożeniem