gitea/deploy
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

feat(astrololo): sekrety logowania i tokenu miedzywarstwowego (LOG-32) #2

Merged
gitea merged 1 commits from feat/auth-secrets into master 2026-07-21 17:06:17 +00:00
Conversation 0 Commits 1 Files Changed 4
+96 -1
gitea commented 2026-07-21 16:53:42 +00:00
Owner
Copy Link
Copy Source

Domyka od strony wdrozenia ochrone dodana w aplikacji
(PR #10 w repo astrololo).
Bez tych zmiennych aplikacja startuje otwarta, a wystawia tresc oryginalnych baz.

Co dochodzi

Usluga Zmienne
presentation APP_PASSWORD + INTERNAL_TOKEN z sekretu; APP_USER, RATE_LIMIT_PER_MIN jawnie (nie sa tajne)
logic INTERNAL_TOKEN z sekretu
data INTERNAL_TOKEN z sekretu

logic i data musza miec token, bo bez niego da sie ominac logowanie, uderzajac
wprost w warstwe nizej — a warstwa danych oddaje surowe wiersze baz.

Wartosci sekretow NIE trafiaja do repo

To repo GitOps: cokolwiek by tu wpadlo, zostaloby w historii gita na zawsze i
przekreslilo caly sens PR #10. Manifesty tylko odwoluja sie do sekretu
astrololo-auth, tworzonego poza repo — ta sama konwencja co istniejacy gitea-registry.

W wyniku kubectl kustomize nie ma zadnego kind: Secret — sprawdzone.

⚠️ Zanim zmergujesz — utworz sekret

Sekret jest wymagany (bez optional: true), wiec pody nie wstana, dopoki go nie
utworzysz. To swiadome: lepsza widoczna awaria niz cichy start bez ochrony.

read -rs -p "Haslo 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 nigdy nie musi go ogladac — sluzy tylko uslugom
do rozmowy miedzy soba. Haslo wpisujesz w przegladarce (uzytkownik astrololo).

Instrukcja zmiany hasla i sprawdzenia po wdrozeniu — w astrololo/README.md.

Weryfikacja

kubectl kustomize dla bazy i profilu swisseph: sekrety trafiaja do wlasciwych uslug,
profil swisseph dziedziczy je poprawnie. engine-swisseph celowo tokenu nie dostaje —
liczy tylko efemerydy, nie oddaje tresci baz (a jego kod i tak by go dzis nie sprawdzil).

Przy okazji poprawiony mylacy komentarz przy EXCEL_DIR: pliki baz ida z NFS, nie
z obrazu — montaz je nadpisuje. W PR-ze o ochronie baz warto, zeby bylo jasne, gdzie one leza.

Co nadal zostaje otwarte

  • Brak TLS — Basic Auth idzie po sieci latwo do podsluchania.
  • NFS 192.168.1.34:/mnt/Tank1/astrololo — kto ma dostep do share'u, bierze pliki baz
    z pominieciem calej aplikacji. To dzis najkrotsza droga do wycieku.
  • Sekret w etcd to tylko base64; docelowo szyfrowanie etcd at-rest albo Sealed Secrets/SOPS.
Domyka od strony wdrozenia ochrone dodana w aplikacji ([PR #10 w repo astrololo](https://gitea.czernobog.pl/gitea/astrololo/pulls/10)). Bez tych zmiennych aplikacja startuje **otwarta**, a wystawia tresc oryginalnych baz. ## Co dochodzi | Usluga | Zmienne | |---|---| | `presentation` | `APP_PASSWORD` + `INTERNAL_TOKEN` **z sekretu**; `APP_USER`, `RATE_LIMIT_PER_MIN` jawnie (nie sa tajne) | | `logic` | `INTERNAL_TOKEN` z sekretu | | `data` | `INTERNAL_TOKEN` z sekretu | `logic` i `data` musza miec token, bo bez niego da sie **ominac logowanie**, uderzajac wprost w warstwe nizej — a warstwa danych oddaje **surowe wiersze baz**. ## Wartosci sekretow NIE trafiaja do repo To repo GitOps: cokolwiek by tu wpadlo, zostaloby w **historii gita na zawsze** i przekreslilo caly sens PR #10. Manifesty tylko **odwoluja sie** do sekretu `astrololo-auth`, tworzonego poza repo — ta sama konwencja co istniejacy `gitea-registry`. W wyniku `kubectl kustomize` **nie ma zadnego `kind: Secret`** — sprawdzone. ## ⚠️ Zanim zmergujesz — utworz sekret Sekret jest **wymagany** (bez `optional: true`), wiec **pody nie wstana**, dopoki go nie utworzysz. To swiadome: lepsza widoczna awaria niz cichy start bez ochrony. ```bash read -rs -p "Haslo 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 nigdy nie musi go ogladac** — sluzy tylko uslugom do rozmowy miedzy soba. Haslo wpisujesz w przegladarce (uzytkownik `astrololo`). Instrukcja zmiany hasla i sprawdzenia po wdrozeniu — w `astrololo/README.md`. ## Weryfikacja `kubectl kustomize` dla bazy **i** profilu swisseph: sekrety trafiaja do wlasciwych uslug, profil swisseph dziedziczy je poprawnie. `engine-swisseph` **celowo** tokenu nie dostaje — liczy tylko efemerydy, nie oddaje tresci baz (a jego kod i tak by go dzis nie sprawdzil). Przy okazji poprawiony mylacy komentarz przy `EXCEL_DIR`: pliki baz ida **z NFS**, nie z obrazu — montaz je nadpisuje. W PR-ze o ochronie baz warto, zeby bylo jasne, gdzie one leza. ## Co nadal zostaje otwarte - **Brak TLS** — Basic Auth idzie po sieci latwo do podsluchania. - **NFS `192.168.1.34:/mnt/Tank1/astrololo`** — kto ma dostep do share'u, bierze pliki baz **z pominieciem calej aplikacji**. To dzis najkrotsza droga do wycieku. - Sekret w etcd to tylko base64; docelowo szyfrowanie etcd at-rest albo Sealed Secrets/SOPS.
gitea added 1 commit 2026-07-21 16:53:43 +00:00
feat(astrololo): sekrety logowania i tokenu miedzywarstwowego (LOG-32) 0509ebd597 
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 merged commit 66d174703e into master 2026-07-21 17:06:17 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
gitea
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gitea/deploy#2
Delete Branch "feat/auth-secrets"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?