L’écosystème des conteneurs a évolué rapidement depuis Docker. Entre les changements de licences, l’émergence d’alternatives comme podman, et la standardisation via containerd, il devient crucial de comprendre les implications techniques, légales et sécuritaires de chaque choix. Cet article détaille les options disponibles.
La transition vers des alternatives à Docker n’est pas seulement une question de coût, mais un véritable choix stratégique de sécurité. En comprenant les implications de chaque runtime, vous pourrez faire des choix éclairés adaptés à vos contraintes opérationnelles et sécuritaires.
L’évolution de Docker et la question des licences
Le changement de licence Docker Desktop
En 2021, Docker Inc. a modifié les conditions d’utilisation de Docker Desktop, rendant l’outil payant pour les entreprises de plus de 250 employés ou générant plus de 10M$ de chiffre d’affaires. Cette décision a provoqué une accélération de la recherche d’alternatives :
- Docker CE (Community Edition) gratuit et open source
- Docker Desktop nécessite un abonnement commercial pour certaines entreprises
- Docker Engine (le daemon) conserve sa licence Apache 2.0
Impact sur les environnements de production
La plupart des déploiements Kubernetes en production n’utilisent plus Docker directement mais s’appuient sur containerd comme runtime de conteneurs depuis la deprecation de dockershim dans Kubernetes 1.24.
containerd : Le runtime de référence
Architecture et avantages
containerd est devenu le runtime de conteneurs standard pour Kubernetes. Développé initialement par Docker puis cédé à la CNCF, il offre plusieurs avantages sécuritaires :
Avantages sécuritaires principaux :
- Architecture minimaliste : Surface d’attaque réduite par rapport à Docker complet
- Isolation renforcée : Support natif des user namespaces pour une isolation au niveau noyau
- Conformité OCI : Adhérence stricte aux standards Open Container Initiative
- Support rootless : Possibilité d’exécution sans privilèges root
- Intégration Kubernetes native : Communication directe via CRI sans couche intermédiaire
containerd 2.0 : Une révolution sécuritaire
Sortie en novembre 2024, containerd 2.0 représente une avancée majeure depuis la version 1.0 de 2017. Cette version apporte des améliorations sécuritaires significatives :
Nouveautés de sécurité 2.0 :
- Image Verifier Plugins
- Validation des images au moment du pull
- Application de politiques de sécurité personnalisées
- Vérification des signatures et de la provenance des images
- User Namespaces par défaut
- Exécution root dans le conteneur, mais UID non-privilégié sur l’hôte
- Amélioration drastique de la sécurité sans pénalité de performance
- Isolation renforcée entre conteneurs et hôte
- Node Resource Interface (NRI)
- Mécanisme d’extension pour personnaliser la configuration conteneur
- Contrôle fin des ressources et des capacités
- Intégration de politiques de sécurité personnalisées
Podman : Alternative rootless et daemonless
Pourquoi Podman ?
Podman (Pod Manager) est une alternative à Docker qui n’utilise pas de daemon central et peut fonctionner en mode rootless, réduisant considérablement les risques sécuritaires.
Avantages sécuritaires :
- Pas de daemon privilégié : Élimine le point de défaillance unique
- Exécution rootless native : Réduction de 70% de la surface d’attaque
- Compatible OCI et Docker CLI : Migration transparente depuis Docker
- Intégration systemd native : Gestion des conteneurs comme services système
Nouveautés 2026 : Podman 5.x
Podman a adopté un cycle de release trimestriel depuis la version 5.3 (novembre 2024), apportant des améliorations continues en 2025-2026 :
Sécurité renforcée :
- Disponibilité 99.99% dans les déploiements edge (pas de SPOF)
- Support amélioré des SELinux contexts
- Isolation renforcée des réseaux utilisateurs
CRI-O : Runtime optimisé pour Kubernetes
CRI-O est un runtime de conteneurs léger spécialement conçu pour Kubernetes, implémentant les spécifications CRI (Container Runtime Interface).
Architecture et philosophie :
- Minimalisme : Uniquement ce qui est nécessaire pour Kubernetes
- Pas de fonctionnalités superflues : Surface d’attaque minimale
- Intégration native CRI : Communication directe avec kubelet
Avantages sécuritaires :
- Exécution rootless : Support complet du mode rootless
- Isolation par défaut : User namespaces et SELinux activés nativement
- Politique de sécurité stricte :
- Drop des capabilities non nécessaires par défaut
- Read-only root filesystem supporté
- No new privileges enforced
- Audit et logging : Traçabilité complète des opérations conteneur
- OCI Runtime modulaire : Support de runtimes sécurisés comme gVisor et Kata Containers
Cas d’usage recommandés :
- Clusters Kubernetes de production
- Environnements multi-tenant
- Déploiements nécessitant une conformité stricte (PCI-DSS, HIPAA)
Comparaison sécuritaire des runtimes
| Runtime | Daemon | Rootless | OCI Compatible | Kubernetes natif | Version 2026 | Sécurité |
|---|---|---|---|---|---|---|
| Docker Engine | Oui | Stable | Oui | Non (deprecated) | 27.x+ | Moyen |
| containerd | Oui | Oui (défaut v2.0) | Oui | Oui | 2.0+ | Très élevé |
| Podman | Non | Oui (natif) | Oui | Via CRI | 5.x | Très élevé |
| CRI-O | Non | Oui | Oui | Oui | 1.3x+ | Élevé |
Bonnes pratiques et recommandations
Pour les environnements de développement (2026)
- Privilégier Podman en mode rootless pour le développement local
- Compatible Docker CLI : alias
alias docker=podman - Podman Desktop pour une interface graphique
- Support natif dans Visual Studio 2026 Insiders
- Compatible Docker CLI : alias
- Alternative : Docker Desktop avec licence
- Nécessite un abonnement pour les grandes entreprises (250+ employés OU 10M$+)
- Performances légèrement inférieures à Podman
- Sécuriser les images dès le développement
- Scanner avec Trivy, Grype ou Snyk
- Vérifier les signatures avec Cosign
- Utiliser des images minimales (distroless, Alpine)
Pour les environnements de production
- Runtime Kubernetes : containerd 2.0 ou CRI-O
- containerd 2.0 : Recommandé pour la plupart des cas (maturité, performances)
- CRI-O : Pour les environnements nécessitant un minimalisme strict
- Activer les fonctionnalités de sécurité avancées
- User namespaces (natif dans containerd 2.0)
- Image verifier plugins pour validation des images
- SELinux ou AppArmor selon la distribution
- Seccomp profiles restrictifs
- Politique de sécurité des images
- Signature obligatoire avec Cosign/Sigstore
- Scan continu avec Trivy intégré au pipeline CI/CD
- Pas d’images latest en production
- SBOM (Software Bill of Materials) pour chaque image
- Monitoring et audit
- Logs centralisés des événements conteneurs
- Détection de dérive de configuration
- Alertes sur les CVE critiques dans les images déployées
Conclusion
L’écosystème des conteneurs en 2026 offre des alternatives matures et sécurisées à Docker. La migration vers containerd 2.0 pour Kubernetes et Podman pour le développement local représente une évolution naturelle vers plus de sécurité et de performances.
- ✓ Docker Desktop nécessite un abonnement pour les entreprises de 250+ employés OU 10M$+ de CA depuis 2021.
- ✓ containerd 2.0 (nov 2024) apporte user namespaces par défaut et image verifier plugins pour une sécurité renforcée.
- ✓ Pour le développement : Podman en rootless. Pour Kubernetes : containerd 2.0. Pour le minimalisme strict : CRI-O.
- ✓ Le mode rootless réduit de 70% la surface d'attaque en éliminant le daemon privilégié.
- ✓ 2026 marque la maturité de l'écosystème post-Docker avec des alternatives performantes, sécurisées et conformes OCI.
Ressources et documentation
Documentation officielle :
Guides de sécurité :