chris/OSVauco
1
0
Fork 0
Code Issues 1 Pull Requests Actions 2 Packages Projects Releases Wiki Activity
feat/opax-web-bff-readonly
OSVauco/implementation-plan.md

4.7 KiB
Raw Permalink Blame History

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.