Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Kubernetes Operator Security

cloud

Définition

Un Kubernetes Operator est un pattern logiciel étendant les capacités de Kubernetes en encapsulant la connaissance opérationnelle d'une application dans un contrôleur Kubernetes personnalisé. Les Operators gèrent le cycle de vie d'applications complexes (bases de données, middleware, plateformes ML) de façon automatisée. La sécurité des Operators est critique car ils s'exécutent généralement avec des privilèges élevés pour effectuer des opérations de gestion sur le cluster. Les risques de sécurité spécifiques aux Kubernetes Operators incluent : des permissions RBAC excessives (les Operators nécessitent souvent des accès cluster-admin pour gérer des ressources dans plusieurs namespaces), la manipulation de Custom Resource Definitions (CRDs) permettant d'injecter des configurations malveillantes via des Custom Resources, les webhooks Admission (Validating/Mutating Webhooks utilisés par les Operators pour valider ou modifier les objets Kubernetes peuvent être exploités), et les vulnérabilités dans le code de l'Operator lui-même (injection, déni de service via des ressources crafted). La sécurisation des Operators Kubernetes suit le principe de moindre privilège appliqué aux permissions RBAC : au lieu d'utiliser le ClusterRole cluster-admin, l'Operator doit recevoir uniquement les permissions nécessaires à son fonctionnement (verbes get, list, watch, create, update pour les resources types spécifiques dans des namespaces spécifiques). L'Operator Framework Operator SDK fournit des outils pour générer automatiquement les manifests RBAC minimalistes basés sur les annotations dans le code de l'Operator. La validaton des Custom Resources (CRs) via des CRD Validation Rules (depuis Kubernetes 1.25) et des Validating Webhooks réduit le risque d'injection via des Custom Resources malformées. Les OpenAPI v3 schemas dans les CRDs définissent les champs autorisés, leurs types, et leurs valeurs valides. Les Validating Webhooks dans les Operators revalidant les CRs soumises permettent d'appliquer des contraintes métier complexes impossibles à exprimer dans les schemas JSON.

Audit RBAC d'un Kubernetes Operator

Auditez les permissions RBAC d'un Operator installé dans votre cluster : kubectl get clusterrole -l app.kubernetes.io/name=OPERATOR_NAME -o yaml pour voir les permissions demandées. Analysez chaque règle RBAC : est-ce que l'Operator a besoin du wildcard * sur les apiGroups ou les verbes ? Des permissions sur des resources sensibles (secrets, nodes, pods/exec) sont-elles justifiées ? Utilisez rbac-tool (github.com/alcideio/rbac-tool) pour visualiser les permissions sous forme de graphe et identifier les excès. Pour les Operators open source, comparez les permissions demandées avec la documentation officielle et ouvrez un issue si elles semblent excessives.

Sécurisation des webhooks Admission Operator

Les webhooks Admission des Operators (Validating et Mutating) doivent être sécurisés : vérifiez que la communication est en mTLS (cert signé par la CA du cluster), que le webhook a un timeout raisonnable (default 10s) et une failurePolicy appropriée (Ignore pour les webhooks non-critiques pour éviter les incidents de disponibilité si l'Operator est down), et que le namespaceSelector exclut les namespaces système (kube-system, kube-public) pour éviter les boucles. Monitorer la latence et la disponibilité des webhooks Operator (une défaillance peut bloquer les déploiements dans tout le cluster).

Operator Lifecycle Manager (OLM) et sécurité

Operator Lifecycle Manager (OLM) est le gestionnaire d'Operators pour les clusters Kubernetes, permettant d'installer, mettre à jour, et gérer les Operators. OLM permet de contrôler les Operators autorisés dans un cluster via les CatalogSources (sources d'Operators approuvés) et les OperatorGroups (namespaces dans lesquels un Operator peut opérer). En production, n'autorisez que des CatalogSources internes ou OperatorHub.io pour les Operators de confiance. Activez les automatic security updates pour les Operators (upgrades automatiques vers les versions patchées) en configurant le channel de mise à jour dans la Subscription OLM.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis