Kubernetes : 7 vulnérabilités critiques que nous trouvons en audit

Kubernetes est puissant mais complexe

Kubernetes orchestre des conteneurs à grande échelle, mais sa surface de configuration est immense. Un cluster mal configuré offre à un attaquant la possibilité de pivoter entre les services, d'exfiltrer des secrets et de compromettre l'ensemble de l'infrastructure. Voici les sept failles que nous trouvons le plus souvent.

1. Pods exécutés en mode privilégié

Un pod avec privileged: true ou hostPID: true a accès au système hôte. Si un attaquant compromet l'application dans ce pod, il s'échappe du conteneur et accède au noeud. De là, il peut pivoter vers les autres pods du cluster.

Vérification : kubectl get pods -o json | jq '.items[].spec.containers[].securityContext'

Correction : appliquez des Pod Security Standards en mode restricted. Aucun pod applicatif ne devrait être privilégié.

2. Secrets Kubernetes en base64, pas chiffrés

Les secrets Kubernetes sont encodés en base64 par défaut, pas chiffrés. Toute personne avec accès en lecture aux secrets du namespace peut les décoder. kubectl get secret db-creds -o jsonpath='{.data.password}' | base64 -d affiche le mot de passe en clair.

Correction : activez le chiffrement at rest des secrets avec un fournisseur KMS. Ou utilisez un gestionnaire de secrets externe (Vault, AWS Secrets Manager) avec un opérateur dédié.

3. RBAC trop permissif

Des ClusterRoleBindings qui donnent cluster-admin à des service accounts applicatifs. Ou des rôles avec des wildcards : resources: ["*"], verbs: ["*"]. Le service account d'un simple microservice a les droits pour supprimer des namespaces entiers.

Correction : appliquez le principe du moindre privilège. Chaque service account ne devrait avoir que les permissions exactes nécessaires dans son namespace.

4. Pas de network policies

Par défaut, tous les pods d'un cluster Kubernetes peuvent communiquer entre eux. Si un attaquant compromet un pod frontend, il accède directement au pod base de données sans passer par l'API. L'absence de network policies est l'équivalent d'un réseau à plat sans segmentation.

Correction : implémentez des NetworkPolicies qui n'autorisent que les flux nécessaires. Commencez par une politique deny-all puis ajoutez les exceptions.

5. API server exposé sans authentification

Le serveur API Kubernetes accessible depuis Internet avec l'authentification anonyme activée. Ou un dashboard Kubernetes exposé sans authentification. C'est la porte ouverte la plus directe vers la compromission totale du cluster.

Vérification : testez curl -k https://[cluster-ip]:6443/api/v1/namespaces depuis l'extérieur.

Correction : désactivez l'accès anonyme, restreignez l'accès à l'API server par réseau, utilisez l'authentification OIDC.

6. Images de conteneurs avec des vulnérabilités connues

Des images basées sur des distributions obsolètes avec des CVE critiques non patchées. Des images latest qui changent sans contrôle. Des images provenant de registres publics non vérifiés.

Correction : scannez les images dans votre CI/CD avec Trivy ou Grype. Utilisez des images distroless ou scratch quand possible. Épinglez les versions avec des digests.

7. Montage du token de service account

Par défaut, chaque pod reçoit un token de service account monté dans /var/run/secrets/kubernetes.io/serviceaccount/token. Si le pod est compromis, l'attaquant utilise ce token pour interroger l'API Kubernetes avec les permissions du service account.

Correction : désactivez le montage automatique avec automountServiceAccountToken: false pour les pods qui n'en ont pas besoin. Utilisez des tokens projetés avec une durée de vie limitée.

L'approche audit

Chez CleanIssue, nous passons en revue la configuration de chaque namespace, les RBAC, les network policies et les security contexts. Parlez-nous de votre revue externe pour identifier les failles de votre cluster.