gitea-mcp-forward-auth

Kleiner Go-basierter Traefik-ForwardAuth-Microservice, der Bearer-Tokens gegen eine konfigurierbare Menge gueltiger Tokens prueft.

Verhalten

• Prueft Authorization: Bearer <token>.
• Validiert Token gegen Tokens aus:
  • AUTH_PROXY_TOKENS_DIR (jede Datei enthaelt genau einen Token), und/oder
  • AUTH_PROXY_TOKENS (kommagetrennte Liste).
• Antwortet mit:
  • 200 (leer) bei gueltigem Token,
  • 401 bei fehlendem/ungueltigem Header oder ungueltigem Token.
• GET /healthz ist immer ohne Auth erreichbar.
• Loggt jeden Auth-Versuch strukturiert, ohne Klartext-Token.

Sicherheitsaspekte

• Token-Matching erfolgt auf Basis von SHA-256-Digests mit crypto/subtle.ConstantTimeCompare.
• Token werden nie im Klartext geloggt; es wird nur ein kurzer Fingerprint (sha256:...) geloggt.
• Start bricht fail-fast ab, wenn keine gueltigen Tokens geladen werden konnten.

Konfiguration (ENV)

• AUTH_PROXY_LISTEN_ADDR
  • Default: :8080
  • Beispiel: :8080
• AUTH_PROXY_TOKENS_DIR
  • Optional
  • Pfad auf ein Verzeichnis, in dem jede Datei einen Token enthaelt (z. B. Kubernetes Secret Volume)
• AUTH_PROXY_TOKENS
  • Optional
  • Kommagetrennte Tokenliste, z. B. token-a,token-b
• AUTH_PROXY_LOG_LEVEL
  • Default: info
  • Werte wie debug, info, warn, error

Hinweis: Es muss mindestens eine Tokenquelle (AUTH_PROXY_TOKENS_DIR oder AUTH_PROXY_TOKENS) konfiguriert sein.

Lokal bauen und starten

go test ./... -v
go vet ./...
go build ./cmd/authproxy

AUTH_PROXY_TOKENS="my-token-1,my-token-2" \
AUTH_PROXY_LISTEN_ADDR=":8080" \
go run ./cmd/authproxy

Beispielaufrufe

# healthcheck (ohne Auth)
curl -i http://localhost:8080/healthz

# fehlender Token -> 401
curl -i http://localhost:8080/

# ungueltiger Token -> 401
curl -i -H "Authorization: Bearer wrong" http://localhost:8080/

# gueltiger Token -> 200
curl -i -H "Authorization: Bearer my-token-1" http://localhost:8080/

Docker

Das Projekt enthaelt ein Multi-Stage-Dockerfile mit statisch gelinktem Binary (CGO_ENABLED=0) und non-root Runtime auf Distroless.

docker build -t gitea-mcp-auth-proxy:dev .
docker run --rm -p 8080:8080 \
	-e AUTH_PROXY_TOKENS="my-token-1,my-token-2" \
	gitea-mcp-auth-proxy:dev

CI/CD (Gitea Actions)

• Build-Workflow: .gitea/workflows/build.yaml
  • Push auf beliebige Branches
  • go vet, go test, go build
  • Kein Registry-Push
• Release-Workflow: .gitea/workflows/release.yaml
  • Trigger auf Tags v*.*.*
  • Buildx-Remote-Builder und Push in Registry
  • latest nur fuer stabile Tags vX.Y.Z
  • Pre-Releases (z. B. v1.2.3-rc1) werden nicht als latest markiert

Wichtig: Dieses Repository baut und pusht nur Images. Das eigentliche Kubernetes-Deployment erfolgt separat ueber FluxCD Image Automation in einem anderen Repository.

Kubernetes-Referenzmanifeste

Referenzbeispiele fuer lokale Verifikation liegen unter:

• deploy/k3s/deployment.yaml
• deploy/k3s/service.yaml

Diese Manifeste sind bewusst minimal und nicht als produktive FluxCD-Quelle gedacht.

Annahmen

• Annahme: Go-Version ist 1.24 (aktuelle stabile Version zum Implementierungszeitpunkt muss ggf. angepasst werden).
• Annahme: Release-Build pusht initial nur linux/amd64.
• Annahme: Remote BuildKit ist im Runner-Netz unter tcp://<default-gateway>:1234 erreichbar.
• Annahme: Registry-Pfad ist gitea.nehmer.net/torben/gitea-mcp-auth-proxy.