
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. 🛡️
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.
« 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 :
- 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.
- 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
<1mssans 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.
| Composant | Statut |
|---|---|
| Scanner principal | Publié / déploiements contrôlés |
| CLI side-car | Publié / déploiements contrôlés |
| Opérateur Kubernetes | Phase de stabilisation |
| SDK WASM | Bêta publiée |
| Intégration passerelle Proxy-Wasm | R&D planifiée |
| Interface de plan de contrôle | R&D planifiée |
| Interception eBPF | R&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_LISTpour é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.
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)
| Entropie | Type de données | Exemple |
|---|---|---|
| 0,0 - 3,0 | Mots courants, répétitions | password, admin, 111111 |
| 3,0 - 3,6 | CamelCase, hachages partiels | ProgramCampaignInstanceJob, 8f3a11b2c |
| 3,6 - 4,5 | Chemins, UUID, mots de passe faibles | /opt/application/runtime, P@ssw0rd2026! |
| 4,5 - 5,0 | Jetons moyens | E8s9d_2kL1 |
| 5,0+ | Clés à haute entropie | (SHA-256, clés API) |
Démarrage rapide
- 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
- 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
PiiPolicyet 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 :
- Tests unitaires : Couvrent les cas limites, le support multilingue et l'intégrité JSON avec une couverture >85 %.
- Fuzzing : Le fuzzing natif Go garantit la sécurité contre les crashs face à des entrées binaires invalides et aléatoires.
- Tests de fumée :
./scripts/test-smoke.shexerce des charges de travail mixtes et rapporte la précision de détection. - Tests de bout en bout (E2E) : La suite
operator/tests/run_e2e.sheffectue 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.