Retour aux mises Ă  jour
New releaseAug 18, 2026

pii-shield v2.2.0

Sidecar K8s sans code pour l'assainissement des logs. Détecte les secrets via l'analyse d'entropie, préserve l'intégrité JSON et masque les PII de manière déterministe. 🛡️

Partager

PII-Shield 🛡️

Side-car de nettoyage de logs sans code pour Kubernetes. Empêche les fuites de données (RGPD/SOC2) en masquant les PII des logs avant qu'ils ne quittent le pod.

PII-Shield fonctionne en processus — CLI, side-car ou WASM. Il n'y a pas d'API hébergée ni de serveur vers lequel vos données sont envoyées.

Release License Docker Pulls Artifact Hub
OpenSSF Best Practices Go Report Card Test Coverage Sponsor

« Ne laissez pas les PII empoisonner vos modèles d'IA. » PII-Shield garantit que les données sensibles n'atteignent jamais votre jeu d'entraînement, vous évitant ainsi un réentraînement forcé du modèle par le RGPD.

[!WARNING] Mise à niveau vers v2.0.0 ? Nous avons déplacé la distribution aux utilisateurs finaux vers des installations basées sur Helm et des side-cars natifs Distroless. Kustomize n'est plus un chemin d'installation pris en charge pour les utilisateurs en production, bien que le dépôt opérateur conserve le scaffolding Kustomize pour le développement local et la génération de manifests. L'accès /bin/sh à l'intérieur du side-car PII-Shield n'est plus pris en charge. Consultez le Guide de migration.

Deux modèles de déploiement

PII-Shield offre deux manières distinctes de s'intégrer à votre pile :

  1. Opérateur Kubernetes (Sans code) : Notre modèle de déploiement phare. Un opérateur K8s entièrement automatisé qui injecte un side-car Distroless hautement sécurisé dans vos pods pour intercepter et assainir les logs à la volée.
  2. WASM en processus (Pour les intégrations noyau) : Pour des performances extrêmes, le moteur central peut être embarqué directement via WASM, offrant une latence <1ms sans sauts réseau.

Statut du projet et feuille de route

PII-Shield est un outil de sécurité open-source activement développé, en phase de durcissement de production. La ligne de versions v2.x livre des artefacts CLI, conteneur, Helm/opérateur et SDK WASM utilisables. Les chemins de masquage principaux sont prêts pour des déploiements contrôlés, tandis que certains modes de déploiement Kubernetes et garanties de chaîne d'approvisionnement sont encore en cours de stabilisation.

ComposantStatut
Scanner principalPublié / déploiements contrôlés
CLI side-carPublié / déploiements contrôlés
Opérateur KubernetesPhase de stabilisation
SDK WASMBêta publiée
Intégration passerelle Proxy-WasmR&D planifiée
Interface de plan de contrôleR&D planifiée
Interception eBPFR&D expérimentale

Voir KNOWN_LIMITATIONS.md pour les limites actuelles du durcissement de production.

Pourquoi PII-Shield ?

Les développeurs oublient souvent de masquer les données sensibles. Les filtres regex traditionnels dans Fluentd/Logstash sont lents, difficiles à maintenir et consomment un CPU coûteux sur les agrégateurs de logs.

PII-Shield se place juste à côté de votre conteneur applicatif :

  • Moteur central durci pour la production : OptimisĂ© pour les side-cars Kubernetes avec de faibles allocations mĂ©moire sur les chemins critiques et une correspondance regex dĂ©terministe.
  • Analyse d'entropie contextuelle : DĂ©tection de secrets Ă  haute entropie mĂŞme sans clĂ©s (ex. Error: ... 44saCk9...) en analysant les mots-clĂ©s contextuels.
  • Règles regex personnalisĂ©es : Masquage dĂ©terministe pour les donnĂ©es structurĂ©es (UUID, ID) qui remplace les vĂ©rifications d'entropie pour les motifs connus.
  • Couverture de rĂ©gression et de fuzzing : TestĂ© contre des cas de stress incluant des dĂ©chets binaires, des JSON imbriquĂ©s et des logs multilingues.
  • Hachage dĂ©terministe : Remplace les secrets par des hachages uniques (ex. [HIDDEN:a1b2c]), permettant Ă  l'assurance qualitĂ© de corrĂ©ler les erreurs sans voir les donnĂ©es brutes.
  • IntĂ©gration immĂ©diate : Aucune modification de code requise. Fonctionne avec n'importe quel langage (Node, Python, Java, Go).
  • Prise en charge de la liste blanche : Autorise explicitement les motifs sĂ»rs (ex. hachages git, ID système) Ă  l'aide de PII_SAFE_REGEX_LIST pour Ă©viter les faux positifs.

Vous gérez PII-Shield sur des dizaines de clusters ?

Nous construisons un plan de contrôle hébergé avec une gestion centralisée des règles, des alertes Slack et des analyses de masquage. Join the Waitlist

Intégrations

La version WASM en processus de PII-Shield est intégrée dans GuardSpine Code, une action GitHub open-source de gouvernance de code IA, qui fournit le binaire et le crédite dans son NOTICE.

Considérations de performance

Bien que PII-Shield soit hautement optimisé, l'inspection approfondie de logs complexes nécessite une attention particulière à la configuration.

  • Logs texte : ExtrĂŞmement rapides (>100k lignes/s).
  • Logs JSON : Analyse sans allocation (aucun surcoĂ»t encoding/json). Le scanner analyse manuellement les structures JSON pour garantir un dĂ©bit Ă©levĂ© (~7 Mo/s) sans pics de mĂ©moire.
  • Recommandation : L'utilisation est sĂ»re pour les dĂ©bits Ă©levĂ©s. Nous utilisons des garde-fous de rĂ©cursion pour prĂ©venir les dĂ©bordements de pile sur les JSON profondĂ©ment imbriquĂ©s.

Installation

Chart Helm (Opérateur Kubernetes)

La manière officielle et recommandée de déployer PII-Shield dans Kubernetes est via notre opérateur entièrement automatisé :

helm repo add pii-shield https://pii-shield.github.io/pii-shield/
helm repo update
helm install pii-shield-operator pii-shield/pii-shield-operator -n operator-system --create-namespace

Cela déploie l'opérateur PII-Shield qui injecte automatiquement des side-cars distroless hautement sécurisés dans vos pods sans nécessiter aucune modification de code ou de Dockerfile.

Docker

Obtenez la dernière image légère depuis Docker Hub ou GHCR :

docker pull thelisdeep/pii-shield:2.2.0
# OU depuis le registre de conteneurs GitHub (Entreprise) :
docker pull ghcr.io/pii-shield/pii-shield:2.2.0

Compilation depuis les sources

Vous pouvez compiler le binaire directement Ă  partir du code source :

go build -o pii-shield ./cmd/cleaner/main.go

Configuration

Voir CONFIGURATION.md pour une liste complète des variables d'environnement, notamment :

  • PII_SALT : Sel HMAC personnalisĂ© (Requis en production).
  • PII_ADAPTIVE_THRESHOLD : Activer les seuils d'entropie dynamiques.
  • PII_DISABLE_BIGRAM_CHECK : Optimiser pour les logs non anglais.
  • PII_CUSTOM_REGEX_LIST : Règles regex personnalisĂ©es pour le masquage dĂ©terministe.
  • PII_SAFE_REGEX_LIST : Règles regex de liste blanche Ă  ignorer (les correspondances sont renvoyĂ©es telles quelles).

Tableau de sensibilité à l'entropie (Seuil par défaut : 3,6)

EntropieType de donnéesExemple
0,0 - 3,0Mots courants, répétitionspassword, admin, 111111
3,0 - 3,6CamelCase, hachages partielsProgramCampaignInstanceJob, 8f3a11b2c
3,6 - 4,5Chemins, UUID, mots de passe faibles/opt/application/runtime, P@ssw0rd2026!
4,5 - 5,0Jetons moyensE8s9d_2kL1
5,0+Clés à haute entropie(SHA-256, clés API)

Démarrage rapide

  1. Test local (CLI) Vous pouvez envoyer n'importe quelle sortie de logs via PII-Shield pour le voir en action immédiatement :
# Émulez un log avec un mot de passe sensible
echo "Error: User password=MySecretPass123! failed login" | docker run -i --rm ghcr.io/pii-shield/pii-shield:2.2.0

# Sortie : Error: User password=[HIDDEN:8f3a11] failed login
  1. Kubernetes (Injection automatisée de side-car) Avec l'opérateur PII-Shield installé, protéger une application est aussi simple que de créer un PiiPolicy et d'étiqueter vos pods.

Créez une politique :

apiVersion: core.pii-shield.io/v1alpha1
kind: PiiPolicy
metadata:
  name: strict-policy
  namespace: default
spec:
  injectionMode: "file"

Étiquetez votre déploiement :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
spec:
  template:
    metadata:
      labels:
        pii-shield.io/inject: "true"
      annotations:
        pii-shield.io/policy: "strict-policy"
# ...

L'opérateur injectera automatiquement l'pii-shield-agent en utilisant le modèle de side-car natif (K8s 1.28+) et masquera de manière sécurisée tous les logs !


📋 Gratuit : Liste de contrôle d'audit PII des logs Kubernetes en 25 points — où les PII fuient depuis les pods, quels chemins de logs contournent vos filtres, et comment vérifier que le masquage fonctionne réellement. Obtenir la liste de contrôle →

📦 Packs de conformité (RGPD/HIPAA/PCI) bientôt disponibles — obtenir un accès anticipé →

💬 Vous utilisez PII-Shield ? Parlez-nous de votre déploiement → — 2 minutes, et cela oriente ce qui sera construit ensuite.

Vérification

Ce projet est vérifié avec une suite de tests en croissance conçue pour renforcer la confiance avant le durcissement de production :

  1. Tests unitaires : Couvrent les cas limites, le support multilingue et l'intégrité JSON avec une couverture >85 %.
  2. Fuzzing : Le fuzzing natif Go garantit la sécurité contre les crashs face à des entrées binaires invalides et aléatoires.
  3. Tests de fumée : ./scripts/test-smoke.sh exerce des charges de travail mixtes et rapporte la précision de détection.
  4. Tests de bout en bout (E2E) : La suite operator/tests/run_e2e.sh effectue une validation complète de la pile à l'aide de Minikube et Helm. Elle construit des images locales, provisionne l'opérateur sans cert-manager, déploie des Jobs cibles et vérifie le masquage réel des logs en interceptant les sorties du side-car.

Benchmark de performance

Pour comparer le débit CLI de bout en bout entre la branche actuelle et une référence de base :

./benchmark/run_benchmarks.sh

Par défaut, le benchmark compare HEAD à origin/main, actualise origin/main, génère un corpus de logs mixte, alterne l'ordre d'exécution ancien/nouveau, et rapporte la médiane, p95, min/max, et MiB/s :

BASE_REF=origin/main RUNS=9 LINES=500000 ./benchmark/run_benchmarks.sh

Cela mesure le chemin CLI complet de stdin à stdout. Pour les micro-benchmarks du scanner uniquement, exécutez :

go test -bench=. -benchmem ./pkg/scanner

Tests d'intégration de l'opérateur

L'opérateur garde des tests unitaires rapides séparés des tests d'intégration de l'API Kubernetes. Les tests réguliers de l'opérateur ne démarrent pas de serveur API local :

cd operator
go test ./...

Pour exécuter la suite d'intégration du contrôleur basée sur envtest :

./scripts/test-operator-integration.sh

Ces tests démarrent un serveur API Kubernetes local et etcd via envtest, ils nécessitent donc la permission de se lier à 127.0.0.1. Dans les environnements sandbox restreints, exécutez-les dans un shell local, un environnement Docker ou un exécuteur CI qui autorise la liaison localhost.

Support

PII-Shield est une infrastructure open-source pour des logs préservant la vie privée. Si ce projet vous est utile, à vous ou à votre organisation, vous pouvez soutenir son développement via GitHub Sponsors.

Vérification des versions

Les instructions de vérification de la somme de contrôle et de l'empreinte d'image des versions sont documentées dans docs/release-verification.md. Les versions adossées à des signatures et à une provenance sont suivies dans le cadre de la feuille de route de durcissement de la chaîne d'approvisionnement.

Licence

Distribué sous la licence Apache 2.0. Voir LICENSE pour plus d'informations.

Catégories