gitea
abc0f98034
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>
80 lines
3.6 KiB
YAML
80 lines
3.6 KiB
YAML
apiVersion: apps/v1
|
|
kind: Deployment
|
|
metadata:
|
|
name: presentation
|
|
namespace: astrololo
|
|
spec:
|
|
replicas: 1
|
|
selector: { matchLabels: { app: presentation } }
|
|
template:
|
|
metadata: { labels: { app: presentation } }
|
|
spec:
|
|
# LOG-33: pody nie rozmawiają z API Kubernetesa, więc token konta
|
|
# serwisowego jest im niepotrzebny — a zamontowany byłby gotowym
|
|
# punktem wyjścia do klastra dla kogoś, kto przejmie kontener.
|
|
automountServiceAccountToken: false
|
|
imagePullSecrets: [{ name: gitea-registry }]
|
|
containers:
|
|
- name: presentation
|
|
image: gitea.czernobog.pl/gitea/astrololo-presentation:9323803c
|
|
ports: [{ containerPort: 8000 }]
|
|
env:
|
|
- name: LOGIC_URL
|
|
value: "http://logic:8001"
|
|
# Logowanie do aplikacji (LOG-32). Bez tych sekretów aplikacja stoi
|
|
# OTWARTA — a wystawia treść baz interpretacyjnych. Sekret tworzony
|
|
# POZA repo (jak gitea-registry) — patrz README.md.
|
|
- name: APP_PASSWORD
|
|
valueFrom:
|
|
secretKeyRef: { name: astrololo-auth, key: APP_PASSWORD }
|
|
- name: INTERNAL_TOKEN
|
|
valueFrom:
|
|
secretKeyRef: { name: astrololo-auth, key: INTERNAL_TOKEN }
|
|
- name: APP_USER
|
|
value: "astrololo"
|
|
- name: RATE_LIMIT_PER_MIN
|
|
value: "120" # 0 = bez limitu
|
|
# Aplikacja stoi za Ingressem, więc bezpośrednim rozmówcą jest zawsze
|
|
# pod Traefika. Bez tego limit żądań liczyłby WSZYSTKICH do jednego
|
|
# wiadra i pierwsza osoba, która go wyklika, odcięłaby pozostałych.
|
|
# Włączać wyłącznie gdy ruch faktycznie idzie przez proxy — inaczej
|
|
# nagłówek staje się furtką do ominięcia limitu.
|
|
- name: TRUST_PROXY
|
|
value: "true"
|
|
# Szyfrowanie łącza między warstwami (PRE-16). OSOBNY klucz na każdą
|
|
# parę rozmówców: przejęcie klucza prezentacji nie otwiera warstwy
|
|
# danych, gdzie leżą całe bazy. Sekret tworzony POZA repo — patrz README.
|
|
- name: LINK_KEY_PRESENTATION_LOGIC
|
|
valueFrom:
|
|
secretKeyRef: { name: astrololo-link, key: LINK_KEY_PRESENTATION_LOGIC }
|
|
# Bez klucza usługa ma NIE wstać, a klient ma nie wysłać niczego.
|
|
# Sam serwer broni się fail-closed, ale to za mało: klient bez klucza
|
|
# zdążyłby wypuścić zapytanie jawnym tekstem, zanim dostanie odmowę.
|
|
# Usługa składająca PDF (PRE-24) — osobny komponent.
|
|
- name: RENDER_URL
|
|
value: "http://render:8004" # discovery po nazwie Service
|
|
# Trzeci klucz łącza: prezentacja ↔ render. Osobny, bo tym łączem
|
|
# idzie CAŁY raport (dane urodzeniowe + opisy z baz).
|
|
- name: LINK_KEY_PRESENTATION_RENDER
|
|
valueFrom:
|
|
secretKeyRef: { name: astrololo-link, key: LINK_KEY_PRESENTATION_RENDER }
|
|
- name: LINK_ENCRYPTION_REQUIRED
|
|
value: "true"
|
|
resources:
|
|
requests: { cpu: "100m", memory: "128Mi" }
|
|
limits: { cpu: "300m", memory: "256Mi" }
|
|
---
|
|
apiVersion: v1
|
|
kind: Service
|
|
metadata:
|
|
name: presentation
|
|
namespace: astrololo
|
|
spec:
|
|
# Wejście z przeglądarki idzie teraz WYŁĄCZNIE przez Ingress po https
|
|
# (ingress.yaml). NodePort był drugą, nieszyfrowaną drogą do środka — czyli
|
|
# obejściem całego PRE-16 — więc znika.
|
|
type: ClusterIP
|
|
selector: { app: presentation }
|
|
ports: [{ port: 8000, targetPort: 8000 }]
|
|
|