Security best practices sur kubernetes

Introduction

Kubernetes est un outil puissant pour la gestion et l’orchestration de conteneurs, mais avec cette puissance vient la responsabilité de sécuriser votre infrastructure. Ce guide couvrira les bonnes pratiques de sécurité pour Kubernetes, y compris la gestion des images, la configuration des permissions, les politiques de réseau, le chiffrement des communications, la sécurité des secrets, la sécurisation de l’ETCD, et les mécanismes de sauvegarde et de restauration. Chaque section fournira des exemples techniques et des explications détaillées pour vous aider à implémenter ces pratiques dans votre environnement Kubernetes.

1. Scan d’Image

Pourquoi ? Les images de conteneurs peuvent contenir des vulnérabilités qui, si elles sont exploitées, peuvent permettre à un attaquant de compromettre votre application ou même l’hôte du conteneur. Le scan d’image permet d’identifier ces vulnérabilités avant que les images ne soient déployées en production.

Quoi scanner ?

  • Repository Insecure : Vérifiez que les images proviennent de dépôts sécurisés.
  • Vulnérabilités OS et Libraries : Utilisez des outils pour scanner les vulnérabilités dans les systèmes d’exploitation et les bibliothèques incluses dans les images.
  • Dépendances Inutiles : Supprimez les dépendances non nécessaires pour réduire la surface d’attaque.

Outil recommandé : Trivy Trivy est un scanner de sécurité de conteneur simple à utiliser qui détecte les vulnérabilités des systèmes d’exploitation et des bibliothèques incluses dans les images de conteneur.

Exemple d’implémentation avec Trivy :

  • Installation de Trivy :
brew install trivy
  • Scan d’une image
trivy image python:3.8-slim
  • Exemple de résultats:

2. Éviter d’exécuter des conteneurs en tant qu’utilisateur root

Pourquoi ? Exécuter des conteneurs en tant qu’utilisateur root augmente les risques de sécurité. Si un attaquant parvient à compromettre le conteneur, il pourrait potentiellement accéder à l’hôte avec des privilèges élevés.

Comment ? Utilisez l’attribut securityContext pour spécifier que le conteneur ne doit pas s’exécuter en tant que root.

Exemple de configuration technique :

3. Configurer les RBAC convenablement

Pourquoi ? La configuration des RBAC (Role-Based Access Control) permet de contrôler précisément qui peut faire quoi dans votre cluster Kubernetes. Le principe de moindre privilège consiste à donner aux utilisateurs et aux services uniquement les permissions dont ils ont besoin pour accomplir leurs tâches.

Mécanisme d’authentification pour les utilisateurs : Kubernetes utilise des certificats pour authentifier les utilisateurs. Les utilisateurs sont authentifiés via des certificats clients émis par une Autorité de Certification (CA). Une fois authentifié, un utilisateur se voit attribuer des rôles et des permissions via les objets RBAC.

Composants principaux de RBAC :

  1. Role et ClusterRole : Définissent des ensembles de permissions.
  2. RoleBinding et ClusterRoleBinding : Associent des rôles à des utilisateurs ou à des groupes d’utilisateurs.
  3. ServiceAccount : Représentent des comptes de services utilisés par des pods pour interagir avec l’API Kubernetes.

Exemple de configuration technique :

  • Création d’un Role :
  • Création d’un RoleBinding
  • Utilisation de kubectl auth can-i pour vérifier les permissions :
kubectl auth can-i get pods --namespace=default --as=jane

4. Mise en place de Network Policies

Pourquoi ? Les Network Policies permettent de contrôler le trafic réseau à destination et en provenance des pods. Cela réduit la surface d’attaque en limitant les communications à ce qui est strictement nécessaire.

Comment ? Les Network Policies spécifient comment les pods sont autorisés à communiquer entre eux et avec d’autres réseaux.

Exemple de configuration technique :

  • Network Policy permettant le trafic HTTP uniquement au pod web

5. Utilisation de Service Mesh comme Istio et mise en place du MTLS entre les pods

Pourquoi ? Un service mesh comme Istio ajoute des fonctionnalités avancées telles que le routage intelligent, la résilience, et la sécurité (MTLS – Mutual TLS) pour les communications entre les services.

Fonctionnalités supplémentaires d’Istio :

  • Observabilité : Tracing, métriques, et logs.
  • Sécurité : Authentification et autorisation intégrées, MTLS.
  • Gestion du trafic : Routage basé sur des règles, gestion des défaillances.

Exemple d’encryption des communications avec MTLS dans Istio :

  • Installation d’Istio :
istioctl install --set profile=demo
  • Activation de MTLS pour un namespace :

Pourquoi ? L’encryption des communications entre les pods garantit que les données échangées ne peuvent être lues que par les parties autorisées. MTLS (Mutual TLS) ajoute une couche de sécurité supplémentaire en authentifiant les deux parties de la communication.

Comment ? MTLS peut être implémenté facilement avec un service mesh comme Istio, qui automatise la gestion des certificats et l’établissement de connexions sécurisées.

  • Exemple de Policy de DestinationRule pour spécifier l’utilisation de MTLS :

7. Sécuriser les secrets Kubernetes

Pourquoi ? Les secrets Kubernetes stockent des informations sensibles telles que des mots de passe et des clés d’API. Il est crucial de sécuriser ces secrets pour empêcher tout accès non autorisé.

Options de sécurisation :

  1. EncryptionConfiguration : Chiffrer les secrets au repos.
  2. Outils externes : Utilisation de Vault, SecretManager, ou Sealed Secrets.

Utilisation de EncryptionConfiguration :

  • Configurer le fichier de configuration d’encryption :
  • Démarrer l’API server avec le fichier d’encryption :
kube-apiserver --encryption-provider-config=/path/to/encryption-config.yaml

Il est aussi possible d’utiliser des outils externes tels que Secret Manager d’AWS avec l’ External secret operator, le CSI secret driver, ou alors les Sealed Secrets. Ces technologies sont détaillées ici: [link]

8. Sécuriser ETCD

Pourquoi ? ETCD stocke toutes les données de configuration de votre cluster Kubernetes. Si ETCD est compromis, l’attaquant pourrait potentiellement accéder à toutes les données et configurations du cluster.

Comment ?

  • Déployer ETCD derrière un firewall.
  • Chiffrer les données au repos.
  • Utiliser des certificats TLS pour les communications.

Exemple de configuration technique pour sécuriser ETCD :

  • Configuration de TLS pour ETCD :
  • Chiffrement des données au repos :

Ajouter la configuration de chiffrement dans ETCD :

etcd --cipher-suites=aes256-gcm

9 – Mise en place d’un mécanisme de backup et restore avec Velero

Pourquoi ? Les sauvegardes régulières garantissent que vous pouvez restaurer votre cluster et vos applications en cas de perte de données ou de défaillance.

Configuration de Velero :

  • Installation de Velero :
velero install \
  --provider aws \
  --bucket <your-bucket> \
  --secret-file ./credentials-velero \
  --use-restic
  • Création d’une sauvegarde
velero backup create my-backup --include-namespaces default
  • Restauration à partir d’une sauvegarde:
velero restore create --from-backup my-backup

10. Configurer des Security Policies avec OPA et Gatekeeper

Pourquoi ? Les policies de sécurité permettent de définir des règles de sécurité qui doivent être respectées lors de la création et la mise à jour des ressources Kubernetes.

Utilisation de OPA Gatekeeper :

  • Installation de Gatekeeper :
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml
  • Définition d’une ConstraintTemplate:
  • Définition d’une Constraint:

Ensemble, la ConstraintTemplate k8srequiredlabels et la Constraint require-app-label font ce qui suit :

  • La ConstraintTemplate définit une règle de validation qui vérifie que les objets Kubernetes ont un label app.
  • La Constraint applique cette règle spécifiquement aux pods. Si un pod est créé ou mis à jour sans le label app, la requête est refusée avec un message d’erreur.

Cela garantit que tous les pods dans le cluster Kubernetes doivent avoir un label app, renforçant ainsi la politique de conformité et facilitant la gestion des ressources.

Conclusion

La sécurité dans Kubernetes est une discipline essentielle pour protéger vos applications et vos données. En suivant ces bonnes pratiques, vous pouvez réduire significativement les risques de sécurité et renforcer la résilience de votre infrastructure. Chaque section de ce guide fournit des exemples concrets et des configurations pratiques pour vous aider à implémenter ces recommandations dans votre environnement Kubernetes. Restez vigilant et continuez à améliorer vos pratiques de sécurité pour vous adapter aux nouvelles menaces et aux évolutions technologiques.