Bonnes Pratiques de Sécurité Kubernetes | Decripte Security

Kubernetes a révolutionné l'orchestration et la gestion des conteneurs à grande échelle, devenant le standard de facto pour le déploiement des applications cloud-native, mais son architecture distribuée et sa complexité inhérente introduisent une surface d'attaque considérablement élargie par rapport aux modèles de déploiement traditionnels. Un cluster Kubernetes typique implique des dizaines de composants interconnectés - API server, etcd, scheduler, controller manager, kubelet, kube-proxy - chacun avec ses propres vulnérabilités potentielles et ses exigences de hardening spécifiques. La nature dynamique de K8s, où les pods sont constamment créés et détruits, où les workloads migrent entre les nodes, et où les politiques de réseau doivent être appliquées en temps réel, fait de la sécurité un défi multidimensionnel qui exige une approche de défense en profondeur. Les configurations non sécurisées par défaut, telles que des permissions excessivement permissives dans RBAC, l'absence de network policies permettant une communication illimitée entre les pods, des conteneurs exécutés en tant que root avec des capacités privilégiées, et des secrets stockés en texte clair dans un etcd non chiffré, représentent des vecteurs d'attaque couramment exploités dans des environnements K8s mal configurés. Cet article explore les pratiques fondamentales de hardening des clusters Kubernetes, couvrant le contrôle d'accès basé sur les rôles (RBAC), les pod security standards, les network policies pour la micro-segmentation, la gestion sécurisée des secrets, les admission controllers pour le policy enforcement, la surveillance de la sécurité en runtime avec des outils tels que Falco, et la conformité aux benchmarks de l'industrie tels que le CIS Kubernetes Benchmark, fournissant une feuille de route complète pour construire et exploiter des clusters Kubernetes sécurisés dans des environnements de production.

Architecture de Sécurité K8s

Un cluster Kubernetes possède plusieurs composants critiques :

• Control Plane : API Server, etcd, scheduler, controller manager
• Nodes : kubelet, kube-proxy, container runtime
• Add-ons : DNS, dashboard, ingress controllers

RBAC (Role-Based Access Control)

RBAC est le fondement de la sécurité K8s, contrôlant qui peut accéder à quoi via l'API server.

Configuration RBAC

      # Role pour lire les pods dans un namespace spécifique
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
      namespace: production
      name: pod-reader
      rules:
      - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "list"]
      ---
      # RoleBinding associe le role à un utilisateur
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
      name: read-pods
      namespace: production
      subjects:
      - kind: User
      name: jane
      apiGroup: rbac.authorization.k8s.io
      roleRef:
      kind: Role
      name: pod-reader
      apiGroup: rbac.authorization.k8s.io
      

Principes RBAC

• Least privilege : N'accorder que les permissions nécessaires
• Éviter ClusterAdmin : Créer des rôles spécifiques par fonction
• Service accounts : Chaque pod doit avoir un SA dédié
• Namespace isolation : RoleBindings plutôt que ClusterRoleBindings

Pod Security

Pod Security Standards

Kubernetes 1.25+ utilise Pod Security Admission à la place des PSPs dépréciées :

• Privileged : Sans restriction, pour les workloads de confiance
• Baseline : Restrictivité minimale, prévient les escalades connues
• Restricted : Fortement restreint, suit les bonnes pratiques de hardening

Security Context

      apiVersion: v1
      kind: Pod
      metadata:
      name: secure-pod
      spec:
      securityContext:
      runAsNonRoot: true
      runAsUser: 1000
      fsGroup: 2000
      seccompProfile:
      type: RuntimeDefault
      containers:
      - name: app
      image: myapp:latest
      securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
      drop:
      - ALL
      

Network Policies

Par défaut, les pods peuvent communiquer librement. Les Network Policies implémentent la segmentation :

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
      name: api-allow-from-frontend
      namespace: production
      spec:
      podSelector:
      matchLabels:
      app: api
      policyTypes:
      - Ingress
      ingress:
      - from:
      - podSelector:
      matchLabels:
      app: frontend
      ports:
      - protocol: TCP
      port: 8080
      

Gestion des Secrets

• Ne jamais coder en dur les secrets : Utiliser Kubernetes Secrets ou des vaults externes
• etcd encryption : Activer l'encryption-at-rest pour etcd
• External Secrets Operator : Intégrer avec Vault, AWS Secrets Manager
• Rotation des secrets : Mettre en place une rotation automatique
• RBAC pour les secrets : Restreindre qui peut lire les secrets

Image Security

• Private registries : Ne pas utiliser de registries publics en production
• Image scanning : Trivy, Clair, Anchore pour le scan de vulnérabilités
• Image signing : Cosign pour vérifier l'intégrité
• Admission controllers : Valider les images avant le déploiement
• Distroless images : Minimiser la surface d'attaque

Admission Controllers

Hardening de l'API Server

• Activer l'audit logging
• Utiliser TLS pour toutes les communications
• Désactiver l'anonymous auth
• Mettre en place l'API rate limiting
• Restreindre l'accès à l'API server (network ACLs)

Runtime Security

• Falco : Détection de menaces en runtime pour K8s
• Sysdig Secure : Protection en runtime et compliance
• Aqua Security : Sécurité des conteneurs sur tout le cycle de vie

Compliance et Audit

• CIS Kubernetes Benchmark : Framework de hardening
• kube-bench : Vérifications automatisées de compliance CIS
• kube-hunter : Outil de penetration testing pour K8s
• Audit logs : Centraliser dans un SIEM pour analyse

Service Mesh Security

Les service meshes (Istio, Linkerd) ajoutent une couche de sécurité :

• mTLS automatique entre les pods
• Politiques d'autorisation fine-grained
• Chiffrement du trafic in transit
• Observability et auditability