112 lines
4.7 KiB
Markdown
112 lines
4.7 KiB
Markdown
# Implementeringsplan: www.opax.work
|
||
|
||
## Fase 0 — Manglende beslutningsgrunnlag
|
||
|
||
**Forutsetninger:** Tilgang til Gitea-repo og Google Cloud-prosjektet.
|
||
|
||
**Endringer:**
|
||
|
||
1. **Lokaliser `opax-hub` kildekode:**
|
||
* Identifiser Gitea-repo og commit/tag som matcher det aktive `opax-hub` container-imaget.
|
||
2. **Verifiser `osvauco-agent` internt API:**
|
||
* Gjennomgå kildekoden for `osvauco-agent` for å verifisere dets interne API og om det har MCP-rutingslogikk.
|
||
|
||
**Beslutningskriterier:**
|
||
|
||
* Basert på kildekodetilgang og -kvalitet for `opax-hub`, avgjør om den skal videreføres og herdes, eller om `opax-web` skal bygges som en ny tjeneste.
|
||
|
||
**Risiko:** Lav. Read-only operasjoner.
|
||
|
||
**Godkjenningspunkt:** Presentasjon av funn og anbefaling for Fase 2.
|
||
|
||
## Fase 1 — Sikkerhetsopprydding (separat fra webterminalen)
|
||
|
||
**Forutsetninger:** Eierskap og avhengigheter for de usikre tjenestene er kjent.
|
||
|
||
**Endringer:**
|
||
|
||
1. **Roter `gitea-chat-bridge` webhook:**
|
||
* Opprett ny webhook.
|
||
* Oppdater `gitea-chat-bridge` distribusjonskonfigurasjon til å bruke den nye webhooken fra Secret Manager.
|
||
* Verifiser at den nye webhooken fungerer.
|
||
* Tilbakekall den gamle webhooken.
|
||
2. **Håndter `osvx-mcp` tjenester:**
|
||
* Lag en plan for å enten avvikle, stramme inn IAM, eller migrere funksjonaliteten til en sikker tjeneste.
|
||
3. **Oppdater incident-notat:**
|
||
* Tildel eier og sett tidsfrister for opprydding.
|
||
|
||
**Risiko:** Medium–høy. Rotasjon av en brukt webhook og endring av Cloud Run-konfigurasjon kan bryte varslinger eller drift dersom avhengigheter ikke er kjent.
|
||
|
||
**Rollback:** Behold fungerende erstatter verifisert før gammel webhook tilbakekalles, og dokumenter påvirkede integrasjoner.
|
||
|
||
**Godkjenningspunkt:** Godkjenning av planen for hver av de tre endringene.
|
||
|
||
## Fase 2 — Web-lag
|
||
|
||
**Forutsetninger:** Beslutning fra Fase 0 er tatt.
|
||
|
||
**Endringer:**
|
||
|
||
1. **Harden `opax-hub` eller bygg `opax-web`:**
|
||
* Implementer nødvendige endringer for å sikre applikasjonen.
|
||
2. **Konfigurer OAuth for produksjon:**
|
||
* Sett OAuth callback til `https://www.opax.work/auth/callback`.
|
||
3. **Stram inn CORS:**
|
||
* Sett `ALLOWED_ORIGINS` til `https://www.opax.work`.
|
||
4. **Dedikert Service Account:**
|
||
* Opprett en dedikert service account for weblaget med minimalt med rettigheter.
|
||
|
||
**Risiko:** Medium. Ny offentlig OAuth-webapp kan påvirke callback-registrering, cookie-domene, CORS, brukerinnlogging og domeneruting.
|
||
|
||
**Godkjenningspunkt:** En eksplisitt pre-go-live sikkerhetstest.
|
||
|
||
## Fase 3 — Intern kjede
|
||
|
||
**Forutsetninger:** Kildekodegjennomgang har bekreftet call graphen.
|
||
|
||
**Endringer (betinget av kodegjennomgang):**
|
||
|
||
1. **Implementer `opax-web/hub` → `osvauco-agent` kall:**
|
||
* Hvis kodegjennomgang bekrefter dette, implementer sikker service-to-service kall med ID-token.
|
||
2. **Implementer `osvauco-agent` → MCP-gateway kall:**
|
||
* Hvis kodegjennomgang bekrefter dette, implementer kall til den herdede MCP-gatewayen.
|
||
3. **IAM-herding:**
|
||
* Forbered og gjennomgå en eksakt, reverserbar IAM-diff som fjerner `allUsers` først etter at navngitte service accounts er verifisert med minst nødvendige invoker-rettigheter og call path er testet.
|
||
|
||
**Risiko:** Høy. Endringer i IAM kan påvirke eksisterende integrasjoner.
|
||
|
||
**Rollback:** Gjenopprett den forrige policyen fra en lagret policy-eksport.
|
||
|
||
**Godkjenningspunkt:** Godkjenning av IAM-diff før anvendelse.
|
||
|
||
## Fase 4.0 / pre-go-live sjekkliste
|
||
|
||
- [ ] Riktig OAuth redirect URI er registrert
|
||
- [ ] Allowlist og autorisasjon er testet server-side
|
||
- [ ] Cookies bruker Secure, HttpOnly og bevisst SameSite-policy
|
||
- [ ] CORS/origin-regler er begrenset til godkjente origins
|
||
- [ ] Ingen secretverdier finnes i klientbundle, Git, Cloud Run literal env eller logger
|
||
- [ ] IAM-policyer er eksportert og gjennomgått før og etter endring
|
||
- [ ] Rollback-eier, DNS TTL og verifisert rollback-prosedyre er fastsatt
|
||
- [ ] Observability, feilhåndtering og health checks er på plass
|
||
|
||
## Fase 4 — Domene og deploy
|
||
|
||
**Forutsetninger:** Alle tidligere faser er fullført og godkjent.
|
||
|
||
**Endringer:**
|
||
|
||
1. **Undersøk domene/sertifikat-mekanisme:**
|
||
* Avgjør den beste måten å håndtere domene og sertifikat basert på eksisterende DNS, Cloud Run domain mapping, eller en eksisterende global HTTPS load balancer.
|
||
2. **Deploy til produksjon:**
|
||
* Deploy den nye/herdede webtjenesten til Cloud Run.
|
||
3. **Konfigurer DNS:**
|
||
* Konfigurer DNS for `www.opax.work` til å peke til den nye tjenesten.
|
||
|
||
**Risiko:** Høy. Feilkonfigurering kan føre til nedetid.
|
||
|
||
**Testing:**
|
||
|
||
* Verifiser først mot godkjent preview-/staging-endepunkt eller Cloud Run-URL; etter eksplisitt go-live-godkjenning verifiseres `www.opax.work`.
|
||
|
||
**Godkjenningspunkt:** Godkjenning av DNS-endringer. |