Quand on me demande « quelle configuration précise de pare-feu et d'authentification mettre en place pour sécuriser un cluster Kubernetes en production », j'ai tendance à répondre : il n'y a pas une seule recette magique, mais un ensemble cohérent de mesures réseau, d'authentification et d'autorisation qui, combinées, réduisent drastiquement la surface d'attaque. Dans cet article je vais partager une configuration concrète et reproductible, basée sur des retours d'expérience en production, des bonnes pratiques Kubernetes et des intégrations courantes (OIDC, mTLS, Vault, cloud security groups).

Définir le modèle de menace

Avant toute règle de pare-feu ou choix d'authentification, posez-vous ces questions : qui doit communiquer avec l'API server ? Quels nœuds doivent s'échanger du trafic entre eux ? Avez-vous des workloads multi-tenant ? Le cluster est-il dans un cloud public, sur bare metal, ou hybride ?

Mon approche : limiter au maximum les accès entrants à l'API et aux composants sensibles, segmenter le réseau (plan de contrôle vs. plan de données), forcer l'authentification forte (OIDC ou certificats rotatifs), et activer toutes les protections natives (RBAC, admission controllers, audit logging).

Sécuriser le plan de contrôle : pare-feu et règles réseau

Le plan de contrôle (API server, controller-manager, scheduler, etcd) doit être isolé. Je recommande :

  • Placer l'API server derrière un load balancer interne (si vous n'avez pas besoin d'exposition publique) et n'autoriser que des IPs / rangs réseau précis (bastion, CI/CD, équipes d'exploitation).
  • Bloquer l'accès direct à etcd : seules les IPs des masters et éventuellement une IP d'admin doivent communiquer sur le port etcd.
  • Utiliser des security groups (AWS), NSGs (Azure), ou des ACL réseau pour appliquer des règles au niveau infra.

    • Voici un tableau récapitulatif des ports et règles que j'applique systématiquement :

    Service Port Source recommandée Destination But
    API Server (HTTPS) 6443 Bastion, CI/CD, IPs d'opérations, kubelets Control plane Contrôle du cluster
    etcd 2379-2380 Masters uniquement etcd Stockage d'état
    kubelet API 10250 Control plane, admin IPs Noeuds Commandes d'administration (TLS requis)
    kubelet read-only 10255 (désactiver si possible) — — À bloquer ; n'exposer jamais
    NodePort range 30000-32767 Limitez si possible Noeuds Accès aux services exposés
    Etc. (SSH) 22 Bastion IPs Noeuds / Masters Administration sécurisée

    Remarques pratiques :

  • Désactivez le port kubelet 10255 (read-only) via la configuration du kubelet. C'est une source fréquente d'informations sensibles exposées.
  • Appliquez des règles egress pour limiter les connexions sortantes des nœuds et des pods (par exemple bloquer les sorties vers IPs connues malveillantes ou limiter accès internet de workloads sensibles).
  • Si vous êtes en cloud, préférez les security groups/NSG + réseaux privés plutôt que de vous reposer uniquement sur iptables sur les nœuds.

    • Network Policies et CNI : micro-segmentation

    Le pare-feu côté hôte ne suffit pas pour limiter la communication entre pods. J'active systématiquement des Network Policies (via Calico ou Cilium) pour restreindre les flux inter-pods :

  • Par défaut, appliquer une politique "deny all" pour les namespaces sensibles, puis autoriser explicitement les communications nécessaires.
  • Utiliser des labels pour créer des règles basées sur le rôle : front-end, backend, db.
  • Activer l'inspection L7 si vous utilisez Cilium/Envoy pour contrôler les appels HTTP entre services.

    • Authentification : OIDC, certificats et service accounts

    Pour l'authentification des utilisateurs humains et des services, voici ce que je mets en place :

  • OIDC pour les utilisateurs : connectez le cluster à un provider OIDC (Keycloak, Dex, Azure AD, Google) pour gérer SSO, MFA et expiration des tokens. Configurez le kube-apiserver avec --oidc-issuer-url, --oidc-client-id, --oidc-username-claim.
  • Certificats pour les composants : kubelets, kube-proxy et autres agents doivent utiliser des certificats mTLS signés par une CA interne. Activez la rotation automatique des certificats (cert-manager ou mécanismes natifs du cloud).
  • Service Accounts et Workload Identity : remplacez l'usage de tokens statiques par des jetons à courte durée et, si possible, par une intégration de type Workload Identity (GKE Workload Identity, IAM Roles for Service Accounts sur AWS) pour liaison fine avec les services cloud.
  • Interdiction des comptes à privilèges globaux : ne pas utiliser les tokens admin globaux pour des apps ; privilégiez des rôles RBAC minimaux.

    • RBAC, Admission Controllers et politiques d'admission

    RBAC est indispensable. Mes règles :

  • Création de rôles et rolebindings précis : pas de ClusterRoleBinding "cluster-admin" pour des équipes non admin.
  • Activer des admission controllers : PodSecurityPolicy (ou Pod Security Admission), NamespaceLifecycle, ValidatingAdmissionWebhook, MutatingAdmissionWebhook, NodeRestriction. Ces contrôleurs préviennent la création de pods privilégiés, exécution en root, hostPath non autorisé, etc.
  • Utiliser des webhooks pour faire appliquer des scans d'image (Trivy, Clair), signatures d'images (Cosign) et politiques d'authentification d'images avant admission.

    • Authentification kubelet & flags pratiques du kube-apiserver

    Paramètres utiles du kube-apiserver que j'active :

  • --anonymous-auth=false
  • --authorization-mode=RBAC,Node
  • --authentication-token-webhook-config-file pour déléguer la validation des tokens si besoin
  • --audit-log-path et --audit-policy-file pour recueillir les traces

    • Et côté kubelet :

  • Activer TLS avec certificats signés (--tls-cert-file, --tls-private-key-file)
  • --read-only-port=0 pour désactiver le port 10255
  • Limiter l'accès via --authentication-token-webhook et --authorization-mode=Webhook/Node

    • Gestion des secrets et rotation

    Ne laissez pas Kubernetes Secrets non chiffrés dans etcd. Mes recommandations :

  • Activer encryption at rest pour etcd (EncryptionConfiguration) et n'autoriser les clé de chiffrement gérées (KMS) côté cloud ou HashiCorp Vault.
  • Utiliser Vault ou SealedSecrets/External Secrets pour injecter les secrets côté runtime.
  • Mettre en place une cadence de rotation automatique pour tokens, certificats et clés.

    • Monitoring, alerting et audits

    Un pare-feu ne suffit pas sans visibilité. J'installe :

  • Audit logging du kube-apiserver envoyé vers un SIEM (ELK, Splunk).
  • Alertes sur échecs d'authentification massifs, création de ClusterRoleBinding, ou appels d'API suspects.
  • Outils de détection runtime (Falco), scan d'images en pipeline CI et contrôle de la chaîne d'approvisionnement (immuabilité d'images, signatures).

    • Quelques exemples concrets de règles

    Exemples que j'applique :

  • Security group API Server : inbound 6443 depuis 10.0.0.0/24 (Bastion & CI), SSH 22 seulement depuis l'adresse de l'équipe, etcd 2379-2380 seulement entre masters.
  • iptables/nftables : bloquer tout vers 10255 et n'autoriser 10250 que depuis l'API server IP.
  • NetworkPolicy par namespace : default deny, allow only port 80/443 from ingress controller et autoriser le trafic HTTPS vers les services backend nécessaires.

    • Mettre en place cette combinaison (contrôle réseau strict, OIDC+certificates, RBAC fin, admission controllers, chiffrement at rest et monitoring) m'a permis de réduire notablement les incidents de sécurité dans des environnements sensibles. Si vous voulez, je peux vous fournir un exemple de configuration de NetworkPolicy pour un namespace "frontend" et un snippet de configuration OIDC pour kube-apiserver adapté à Keycloak.