Supporter des secrets structurés et des politiques de backend #11

Merged

thibaud-lclr merged 0 commits from refs/pull/11/head into main

2026-04-13 15:18:44 +00:00

thibaud-lclr commented

2026-04-13 15:03:27 +00:00

(Migrated from gitea.lclr.dev)

Résumé

ajout de BackendPolicy avec auto, kwallet-only, keyring-any et env-only
conservation du cas simple string via SetSecret / GetSecret / DeleteSecret
ajout de helpers JSON SetJSON, GetJSON et GetJSONInto pour les secrets structurés
ajout d'erreurs explicites pour les backends indisponibles et les backends en lecture seule
ajout de tests unitaires sur les policies, le fallback environnement et les secrets structurés
mise à jour de la documentation du package secretstore

Validation locale

go test ./...

Proposition de validation via graylog-mcp

Aucun changement immédiat n'est requis dans graylog-mcp pour vérifier l'absence de régression sur le cas simple token/string.

Dans ~/Projets/graylog-mcp, pointer temporairement gitea.lclr.dev/AI/mcp-framework vers ce checkout local, par exemple via un replace ... => ../mcp-framework.
Recompiler graylog-mcp avec go build ./....
Exécuter graylog-mcp setup --profile dev sur une machine avec keyring disponible et vérifier que le token est toujours stocké et relu correctement.
Exécuter graylog-mcp config show --profile dev puis graylog-mcp config test --profile dev pour valider le chargement complet de la configuration.
Vérifier le fallback historique en exportant API_TOKEN puis en lançant graylog-mcp config test --profile dev sans secret stocké.

Issue

Closes #4

## Résumé - ajout de `BackendPolicy` avec `auto`, `kwallet-only`, `keyring-any` et `env-only` - conservation du cas simple `string` via `SetSecret` / `GetSecret` / `DeleteSecret` - ajout de helpers JSON `SetJSON`, `GetJSON` et `GetJSONInto` pour les secrets structurés - ajout d'erreurs explicites pour les backends indisponibles et les backends en lecture seule - ajout de tests unitaires sur les policies, le fallback environnement et les secrets structurés - mise à jour de la documentation du package `secretstore` ## Validation locale - `go test ./...` ## Proposition de validation via graylog-mcp Aucun changement immédiat n'est requis dans `graylog-mcp` pour vérifier l'absence de régression sur le cas simple token/string. 1. Dans `~/Projets/graylog-mcp`, pointer temporairement `gitea.lclr.dev/AI/mcp-framework` vers ce checkout local, par exemple via un `replace ... => ../mcp-framework`. 2. Recompiler `graylog-mcp` avec `go build ./...`. 3. Exécuter `graylog-mcp setup --profile dev` sur une machine avec keyring disponible et vérifier que le token est toujours stocké et relu correctement. 4. Exécuter `graylog-mcp config show --profile dev` puis `graylog-mcp config test --profile dev` pour valider le chargement complet de la configuration. 5. Vérifier le fallback historique en exportant `API_TOKEN` puis en lançant `graylog-mcp config test --profile dev` sans secret stocké. ## Issue Closes #4

thibaud-lclr commented

2026-04-13 15:04:10 +00:00

(Migrated from gitea.lclr.dev)

Aucune évolution bloquante n'est requise dans graylog-mcp pour merger cette PR : le chemin simple token/string reste compatible tel quel.

Si on veut ensuite exposer la nouvelle capacité de politique de backend côté graylog-mcp, je propose ce plan :

Ajouter une configuration explicite de policy (GRAYLOG_SECRET_BACKEND ou flag CLI équivalent) avec les valeurs auto, keyring-any, env-only et kwallet-only.
Mapper cette valeur dans internal/secretstore/store.go vers fwsecretstore.Options{BackendPolicy: ...}.
Ajuster les messages de setup, mcp et config test pour distinguer backend indisponible, backend en lecture seule et fallback environnement.
Ajouter des tests unitaires sur la résolution de la policy et documenter le comportement headless / Linux sans wallet déverrouillé.

Aucune évolution bloquante n'est requise dans `graylog-mcp` pour merger cette PR : le chemin simple token/string reste compatible tel quel. Si on veut ensuite exposer la nouvelle capacité de politique de backend côté `graylog-mcp`, je propose ce plan : 1. Ajouter une configuration explicite de policy (`GRAYLOG_SECRET_BACKEND` ou flag CLI équivalent) avec les valeurs `auto`, `keyring-any`, `env-only` et `kwallet-only`. 2. Mapper cette valeur dans `internal/secretstore/store.go` vers `fwsecretstore.Options{BackendPolicy: ...}`. 3. Ajuster les messages de `setup`, `mcp` et `config test` pour distinguer backend indisponible, backend en lecture seule et fallback environnement. 4. Ajouter des tests unitaires sur la résolution de la policy et documenter le comportement headless / Linux sans wallet déverrouillé.