d4a57cc4f5
Do tej pory aplikacja chodzila po zwyklym http, a logowanie szlo przez HTTP Basic — czyli haslo leciało siecia w postaci trywialnej do podsluchania. Poza bezpieczenstwem TLS naprawia DWIE funkcje zepsute dzis z tego samego powodu: geolokalizacja przegladarki („Tu i teraz") i kopiowanie promptu do schowka dzialaja wylacznie w secure context, wiec po http po prostu odmawialy. Wlasne CA, nie Let's Encrypt — klaster stoi w LAN (traefik trzyma LoadBalancera na 192.168.1.x), wiec walidacja HTTP-01 nie ma jak dojsc z internetu, a DNS-01 wymagalby trzymania w klastrze tokena API do domeny. Co dochodzi: - tls.yaml — Issuer selfSigned -> korzen CA (10 lat, importowany raz do przegladarki) -> Issuer CA -> certyfikat serwera (90 dni, odnawiany sam). Krotki termin certyfikatu serwera jest CELOWY: odnawianie sprawdza sie wtedy co kwartal, a nie dopiero za dekade. - ingress.yaml — wejscie po https + naglowki (HSTS rok, nosniff, frameDeny) oraz osobny Ingress na porcie 80 robiacy przekierowanie. Rozdzielone swiadomie: gdyby redirect wisial na tym samym routerze co wejscie po https, odsylalby sam do siebie w kolko. - presentation: Service NodePort -> ClusterIP. NodePort byl druga, nieszyfrowana droga do aplikacji, czyli obejsciem calego PRE-16. Zmiana wymagajaca uwagi: TRUST_PROXY=true. Za Ingressem bezposrednim rozmowca jest zawsze pod Traefika, wiec bez tego limit zadan liczylby WSZYSTKICH do jednego wiadra i pierwsza osoba, ktora go wyklika, odcielaby pozostalych. Sprawdzone: Ingress i Middleware przechodza `kubectl apply --dry-run=server` na zywym klastrze (CRD traefik.io/v1alpha1 sa, entrypointy web/websecure sa). Obiekty cert-managera zwalidowane offline wobec oficjalnego schematu z CRD v1.21.0 z additionalProperties=false — literowka w nazwie pola zostalaby zlapana. `kubectl kustomize` przechodzi dla obu profili (bazowego i swisseph). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
57 lines
2.1 KiB
YAML
57 lines
2.1 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:
|
|
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"
|
|
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 }]
|
|
|