docs: add automation and sentinel plan for gitea
Some checks are pending
Check Python Version Consistency / Check Python Version (push) Waiting to run

This commit is contained in:
Chris Christiansen 2026-07-25 04:13:16 +00:00
parent 38f8338c6e
commit c320f59599

View File

@ -102,6 +102,96 @@ GITEA_TOKEN: [ROTERT OG FJERNET]
--- ---
### Rollen "automation" og sikkerhets-sentinel for Gitea
Status per 2026-07-25:
- Gitea kjører på https://git.vauco.no med HTTPS og riktig ROOTURL.
- Offentlig registrering er stengt (DISABLE_REGISTRATION = true, ALLOW_ONLY_EXTERNAL_REGISTRATION = true, SHOW_REGISTRATION_BUTTON = false).
- To uautoriserte brukere (dev433f2c, dev1ba0ac) er deaktivert, deres tokens er slettet, og Gitea svarer fortsatt 200 OK lokalt.
- Ingen av stegene under er gjennomført ennå de beskriver målbildet for neste iterasjon med lokale modeller og Gemini i VM.
#### 1. Teknisk Gitea-bruker: `automation`
Mål:
- Skille menneskelig admin (`chris`) fra automatiserte operasjoner.
- Sørge for at alle automatiske commits / API-kall identifiseres som `automation`, ikke `chris`.
Plan:
- Opprett Gitea-bruker `automation` (ikke admin).
- Gi `automation` kun tilgang til de repoene automasjon skal jobbe med (f.eks. OSVauco).
- Bruk CLI/API fra Gitea-VM (Gemini i VM) til:
- Generere ett personal access token for `automation` med begrenset scope (primært repo-API / git).
- Skrive tokenet direkte til Google Cloud Secret Manager (f.eks. secret `gitea-automation-token`).
- Konfigurere Cloud Run / OPAX MCP til å lese tokenet via miljøvariabel (f.eks. `GITEA_TOKEN`).
- Roter og slett gamle tokens (spesielt tidligere GITEATOKEN som var eksponert i chat) via Gitea-API.
- Konfigurer git på Gitea-VM til å bruke `automation` (SSH-nøkkel eller HTTP-token) for push/pull.
Viktig:
- `automation` skal ikke være admin.
- `chris` skal ikke dele token med automasjon.
- Token-verdier lagres kun i Secret Manager og miljøvariabler, ikke i repo eller logs.
#### 2. Sentinel-rolle for lokale LLM-modeller (Gitea Security Sentinel)
Mål:
- Ha en lettvekts, lokal LLM-modell (Emma / annen) som periodisk opptrer som "cyber security sentinel" for Gitea og tilhørende infrastruktur.
- Fange opp mønstre som ligner hendelsen 2026-07-11 (uautoriserte brukere, tokens laget rett etter signup, ukjente repo osv.).
Rolle: `sentinel` (kun lesing + rapport)
Input:
- Gitea-API:
- Liste over brukere, nye accounts, is_active-flagg.
- Liste over personal access tokens per bruker (antall, navn, opprettelsestid).
- Repo-oversikt (nye repo, eierskap).
- Logger:
- Gitea-app-logg (sign_up, generate-access-token, login, push).
- Nginx-logg (IP-mønstre mot /user/sign_up, /api/v1/users/*, etc.).
- journald for gitea.service.
- Konfig:
- app.ini (service, security, auth sections).
- Firewall-regler (gcloud output).
- Secret Manager metadata (f.eks. hvilke secrets som eksisterer, ikke verdiene).
Oppførsel:
- Kjør periodisk (f.eks. hver time eller natt) fra Gitea-VM eller egen planlagt jobb.
- Analyser:
- Nye lokale brukere (ikke OAuth-baserte).
- Nye tokens, spesielt for ikke-kjente brukere.
- Nye repo opprettet av ukjente brukere.
- Uvanlige IP-er / volum på signups eller token-opprettelse.
- Endringer i app.ini som svekker sikkerhet (f.eks. åpnede registreringer, endrede auth-innstillinger).
- Produser en kort rapport i et eget repo, f.eks. `protocols/security/SENTINEL-REPORT-YYYY-MM-DD.md`:
- Oppsummer funn.
- Marker "OK" hvis ingen avvik, ellers beskriv konkrete avvik med tidsstempel.
- Foreta ingen direkte mutasjoner (ingen deaktivering, ingen token-sletting) uten eksplisitt instruks fra overordnet plan eller menneskelig godkjenning.
Alarmsignaler (eksempler):
- Nye lokale brukere med is_active = 1 som ikke matcher forventede mønstre (navn / email).
- Tokens opprettet for brukere utenfor forventet sett (`chris`, `automation` m.fl.).
- Repo opprettet av ukjente brukere (som r6e08-tilfellet).
- app.ini endret slik at DISABLE_REGISTRATION går tilbake til false eller ALLOW_ONLY_EXTERNAL_REGISTRATION endres.
- Logger viser sign_up / generate-access-token mønstre fra samme IP som tidligere ble flagget.
#### 3. Samspill mellom `automation`, `sentinel` og `chris`
- `chris`:
- Fortsatt eneste Gitea-admin.
- Godkjenner større endringer, branch protection, og eventuelle "fix"-operasjoner som `sentinel` foreslår.
- `automation`:
- Utfører godkjente, tekniske endringer (token-rotasjon, oppdatering av Secret Manager, git push/pull).
- Opererer alltid gjennom CLI/API, ikke via web.
- `sentinel`:
- Kjører periodisk analyser, skriver rapporter og flagger avvik.
- Har kun lesetilgang (Gitea-API, logger, metadata), ikke skrive-/admin-tilgang.
Målet:
- Gitea forblir "sannheten" for kode og sikkerhetslogg.
- Automatiserte aktører er tydelig skilt fra menneskelig admin.
- Lokale LLM-modeller brukes til kontinuerlig sikkerhetsobservasjon uten å få fri tilgang til å endre alt.
---
## FASE 6.5 — OPPDATERT LOKAL LLM-STACK (2026-07-22) ## FASE 6.5 — OPPDATERT LOKAL LLM-STACK (2026-07-22)
### Bekreftet drift ### Bekreftet drift