Produksjonsherdning

Anbefalinger for å sikre Lumi-installasjonen i produksjon. Alle eksemplene bruker lumi_sk_live_...-nøkkelen som DevOps-ansvarlig har hentet fra dashboardet.

Origin-validering

pk_-nøkler kan låses til spesifikke origins. Widgeten kan da kun sende inn svar fra tillatte domener — alle andre origins avvises med 403 Forbidden. Nye pk_-nøkler krever minst én allowedOrigins-verdi. Aktive legacy pk_-nøkler uten origins stopper preflight/startup til de er erstattet og revokert, med mindre et eksplisitt midlertidig unntak er slått på. Ikke sett LUMI_ALLOW_UNRESTRICTED_PK_ORIGINS=true i produksjon.

# Opprett en pk_-nøkkel begrenset til produksjonsdomenet
curl -X POST https://lumi.din-bedrift.no/api/v1/admin/api-keys \
  -H "Authorization: Bearer lumi_sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "keyType": "pk",
    "appName": "min-web-app-prod",
    "allowedOrigins": ["https://app.din-bedrift.no"]
  }'

Miljøseparasjon

Bruk separate nøkler for dev, staging og prod — én per team og miljø. Da kan du revokere enkeltmiljøer uten å påvirke de andre.

---

Rate limiting

API-nøkler håndheves med en fast ett-minutts window per nøkkel. Grensen leses fra api_keys.rate_limit og er som standard 1000 forespørsler per minutt per nøkkel. Overskrides grensen, returneres 429 Too Many Requests med Retry-After satt til antall sekunder til neste window.

Valkey og cache

Valkey gir delt rate-limit-state på tvers av API-replikaer og bør være aktivert i multi-replica produksjon. Uten Valkey bruker API-et en per-prosess in-memory limiter, som er korrekt for single-node deploys, men en to-pod deploy kan tillate omtrent dobbelt grense. Endringer i rate_limit tar effekt innen ca. 30 sekunder, tilsvarende API-nøkkeloppslagets cache-TTL.

Valkey-outage

Når Valkey er konfigurert, men utilgjengelig, feiler API-nøkkel-rate-limiteren åpent: submission-kallet får fortsette i stedet for å avvises på grunn av cache-outage. Dette er valgt som standard for å prioritere innsamlings-tilgjengelighet i BYOC-miljøer; det finnes foreløpig ikke en fail-closed-konfig. Outage er synlig i loggen uten API-nøkkelverdier og i Prometheus-metrikken api_key_rate_limiter_fail_open_total. Sett alert på denne metrikken i produksjon.

---

Nøkkelrotasjon

Roter sk_- eller pk_-nøkler uten nedetid ved hjelp av grace period. Den gamle nøkkelen fortsetter å fungere i det angitte antallet timer mens du ruller ut den nye.

# Roter nøkkel med 72 timers grace period
curl -X POST https://lumi.din-bedrift.no/api/v1/admin/api-keys/{id}/rotate \
  -H "Authorization: Bearer lumi_sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{"gracePeriodHours": 72}'

Respons (201 Created):

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "key": "lumi_pk_live_...",
  "keyType": "pk",
  "team": "mitt-team",
  "appName": "min-web-app"
}

Anbefalt rotasjonsrutine:

1. Roter nøkkelen og noter ned den nye verdien
2. Oppdater miljøvariabelen i appen din og deploy
3. Grace period på 72 timer gir rom for gradvis utrulling
4. Den gamle nøkkelen utløper automatisk

---

Revokering (umiddelbar)

Revokering trer i kraft øyeblikkelig og kan ikke angres. Bruk dette ved mistanke om lekkasje.

# Revokere en nøkkel umiddelbart
curl -X DELETE https://lumi.din-bedrift.no/api/v1/admin/api-keys/{id} \
  -H "Authorization: Bearer lumi_sk_live_..."

Respons: 204 No Content

Ugjenopprettelig handling

En revoker nøkkel kan ikke gjenopprettes. Opprett en ny nøkkel og oppdater appen din.

---

Miljøseparasjon

Anbefalt mønster for å holde dev, staging og prod atskilt:

Miljø	Team-slug	Nøkkelprefix	allowedOrigins
Produksjon	produkt-prod	lumi_pk_live_...	https://app.din-bedrift.no
Staging	produkt-staging	lumi_pk_live_...	https://staging.din-bedrift.no
Utvikling	produkt-dev	lumi_pk_test_...	http://localhost:3000

Hvert team har sitt eget sett med nøkler og egne survey-data i dashboardet.

---

Image-policy og pinning

Lumi bruker digest-pinning og CI-kontroller for container- og chart-defaults som inngår i en standard BYOC-deploy.

• Dockerfile base-images skal bruke @sha256:.... scripts/check-image-pins.sh feiler dersom en app-Dockerfile går tilbake til flytende tag.
• Chart init-image i charts/lumi/values.yaml skal være digest-pinnet. Samme guard feiler dersom defaulten mangler digest.
• PostgreSQL og Valkey subcharts rendres med digest-pinnede default-images. scripts/check-third-party-chart-images.test.sh dekker også opt-in metrics exporter, opt-in volume-permissions og intern registry mirror.
• Chart-publisering bruker .Chart.AppVersion for API- og dashboard-images. helm-publish stopper før chart push dersom lumi-api:<appVersion> eller lumi-dashboard:<appVersion> mangler på GHCR.

pin-guard-jobben i CI kjører på PR-er og håndhever image-pinning for app-Dockerfiles og chart init-image. Helm-jobben rendrer i tillegg chartet og fanger brudd i PostgreSQL/Valkey-defaultene. Det tvinger image-endringer gjennom synlig diff og review.

For BYOC-kunder som speiler Bitnami PostgreSQL/Valkey til intern registry, må global.security.allowInsecureImages=true settes sammen med global.imageRegistry, relevante *.image.repository-overrides og de samme *.image.digest-verdiene. Dette gjelder også subchart-valg som metrics exporter og volume permissions. Dette er Bitnami-chartets eksplisitte opt-in for ikke-standard image-kilder, ikke en Kubernetes securityContext-endring.

---

Se også

• API-endepunkter — nøkkeladministrasjon
• Distribuer Lumi — installasjon og oppsett