Cas réel
IronLock dans Docker / Kubernetes

Le défi des containers

IronLock v2 est conçu pour lier un programme à une machine physique. Docker et Kubernetes brisent cette hypothèse : les containers sont éphémères, leur "hardware" est virtualisé, et le même container peut tourner sur 50 nœuds différents. Adapter IronLock à Kubernetes nécessite de repenser le modèle de fingerprint.

Dans Kubernetes, l'unité de déploiement n'est plus la machine — c'est le pod. Le licensing doit s'adapter : on lie la licence au cluster ou au namespace, pas au nœud physique.

Fingerprint dans Docker

Les sources de fingerprint classiques sont inutilisables dans un container :

La stratégie : remplacer le fingerprint hardware par un fingerprint de cluster basé sur des identifiants Kubernetes stables :

from kubernetes import client, config
import hashlib

def get_k8s_fingerprint() -> str:
    config.load_incluster_config()
    v1 = client.CoreV1Api()

    # UUID du namespace (stable)
    ns = v1.read_namespace(
        name=os.environ.get("POD_NAMESPACE", "default")
    )
    ns_uid = ns.metadata.uid

    # UUID du kube-system namespace (identifiant unique du cluster)
    ks = v1.read_namespace(name="kube-system")
    cluster_uid = ks.metadata.uid

    raw = f"{cluster_uid}|{ns_uid}".encode()
    return hashlib.sha256(raw).hexdigest()

Modèles de licensing K8s

Trois modèles selon le niveau de granularité requis :

• Licence par cluster — une seule licence pour tous les pods du cluster. Simple, peu restrictif. UUID du namespace kube-system comme fingerprint.
• Licence par namespace — une licence par environment (prod, staging, dev). UUID du namespace comme fingerprint.
• Licence par réplica (flottant) — N licences flottantes, chaque pod checke out une licence au démarrage. Utile pour limiter le nombre de replicas autorisés.

Sidecar de vérification

Le pattern sidecar isole la logique de vérification de licence dans un container séparé du pod :

# deployment.yaml
spec:
  template:
    spec:
      containers:
      - name: app
        image: monapp:1.1.0
        env:
        - name: LICENCE_CHECK_URL
          value: "http://localhost:8421/check"

      - name: ironlock-sidecar
        image: truvector/ironlock-sidecar:2.0
        ports:
        - containerPort: 8421
        env:
        - name: LICENCE_FILE
          valueFrom:
            secretKeyRef:
              name: ironlock-licence
              key: licence.lic
        - name: PUBLIC_KEY
          valueFrom:
            secretKeyRef:
              name: ironlock-licence
              key: public.pem

# L'application vérifie sa licence via le sidecar (localhost)
import requests

def check_licence_sidecar() -> bool:
    try:
        r = requests.get("http://localhost:8421/check", timeout=2)
        return r.json()["valid"]
    except:
        return False  # sidecar indisponible → bloquer

Gestion des secrets K8s

# Créer le secret K8s avec la licence et la clé publique
kubectl create secret generic ironlock-licence   --from-file=licence.lic=./licences/prod-cluster.lic   --from-file=public.pem=./keys/public.pem   --namespace=production

# Chiffrer le secret avec Sealed Secrets (recommandé)
kubeseal --cert=./sealed-secrets-cert.pem   < ironlock-secret.yaml > ironlock-sealed-secret.yaml

Opérateur K8s custom (optionnel)

Pour les déploiements avancés, un opérateur Kubernetes peut gérer le cycle de vie des licences IronLock automatiquement : renouvellement 30 jours avant expiration, rotation des secrets, alertes Prometheus sur l'état des licences.

Chiffres et performances

• Latence sidecar : < 2ms par vérification (HTTP localhost).
• Fréquence de vérification : toutes les 5 minutes (configurable).
• Overhead CPU : < 0.1% sur un pod standard.
• Temps de démarrage supplémentaire : < 500ms (init du sidecar).

Conclusion

IronLock v2 dans Kubernetes nécessite d'adapter le fingerprint au modèle conteneurisé (UUID namespace/cluster plutôt que hardware). Le pattern sidecar est la solution la plus propre : isolation de la logique de licensing, mise à jour indépendante du sidecar, et secrets K8s chiffrés. La performance est négligeable (< 2ms de latence, < 0.1% CPU).