Cet article consacré à la sécurité de ce qui “tourne” dans Kubernetes est la 6ème partie d’une série dont vous pouvez voir les épisodes précédents sur ce blog.

Gestion des trafics Est-Ouest

Ici il est question de contrôler les communications réseaux entre les pods instanciés au sein d’un cluster.

Par défaut, l’ensemble des pods sont déployés sur le même segment réseau et peuvent donc se voir (communiquer entre eux). Si le cluster héberge plusieurs applications distinctes, alors on obtient un joyeux mélange où la segmentation devrait faire sens.

La première solution permettant d’effectuer de la segmentation réseau au sein d’un cluster Kubernetes est l’utilisation de Network Policies.

Une network policy défini comment des groupes de pods sont autorisés à communiquer avec d’autres groupes ou avec des endpoints / services. Cela permet de verrouiller le trafic depuis ou vers des ensembles de pods en fonction de metadata, namespaces grâce à des règles sur les IP et les numéros de ports.

Les Network Policies fournissent ainsi un contrôle dans les couches 3 et 4 du modèle OSI des communications entre des pods et des entités réseaux (autres pods, endpoint, services)

Dans Azure Kubernetes Services, 2 options permettent l’usage des Network Policies :

• L’implémentation propre à Azure appelée Azure Network Policies
• La solution Open Source Calico Network Policies de Tigera

Le choix entre ces 2 options dépend généralement du type de node pool utilisé (Linux ou Windows), du plugin réseau utilisé (Azure CNI ou kubenet), de fonctions particulières, du niveau de support attendu (support Azure, support Communautaire ou support payant Tigera) et de la manière dont est faite la journalisation. Un tableau résume tout cela dans la documentation Azure.

A quoi ressemble une Network Policy ? Comme tout objet dans Kubernetes : à un manifest YAML 🙂

Pour vous aider dans la validation ou la lecture de fichiers YAML décrivant des objets de type network policy, il existe des outils comme Tufin (https://orca.tufin.io/netpol/)

Des tonnes d’exemples de network policies sont disponibles. Je trouve le repo suivant très bien fait : https://github.com/ahmetb/kubernetes-network-policy-recipes

Pod Security Policy

Une Pod Security Policy est une ressource au niveau du cluster qui permet d’appliquer des règles sur les aspects sécurité des spécifications d’un pod et qui affecte le contexte de sécurité appliqué à celui-ci.

Cette fonctionnalité est désormais dépréciée dans le projet Kubernetes depuis la version 1.21 et sera retirée dans la version 1.25 (cf. https://kubernetes.io/docs/concepts/policy/pod-security-policy/ et https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/).

Le support de Pod Security Policy dans AKS ne sortira donc pas du statut de preview et son retrait d’AKS sera aligné avec le projet Kubernetes et sera donc effectif dans la version 1.25 (cf. https://github.com/Azure/AKS/blob/master/CHANGELOG.md#release-2021-07-29)

Le successeur de PSP est certainement le Pod Security Admission qui arrive en beta dans la version 1.23 de Kubernetes

Microsoft Defender for containers

Microsoft Defender for containers est une solution cloud native de sécurisation des conteneurs résultant de la fusion (depuis décembre 2021) de deux solutions qui s’appelaient Azure Defender for Kubernetes et Azure Defender for Container registries. En complément de cette fusion, de nouvelles capacités ont été ajoutées.

Point important : cette solution ne se limite pas uniquement aux clusters AKS dans Azure mais fonctionne également sur tout cluster Kubernetes certifié par la Cloud Native Computing Foundation (d’où probablement aussi le changement de nom Azure Defender -> Microsoft Defender).

Microsoft Defender for containers va aider à améliorer la sécurité sur 3 aspects :

1- Durcissement de l’environnement : les clusters Kubernetes sont évalués en continu et Azure Defender for containers donne de la visibilité sur les mauvaises configurations et propose des pistes d’amélioration pour limiter le risque face à des menaces identifiées

2- Scan et évaluation de vulnérabilités : pour les images stockées dans Azure Container Registry et les images exécutées dans Azure Kubernetes Service. La technologie de scan utilisée est fournie par Qualys.

Plus d’informations : Scanning images in ACR registries

3- Protection contre les menaces sur les nodes / hosts / cluster : analyse des journaux d’audit de Kubernetes et détection des menaces au niveau des hosts basé sur une grosse soixantaine de critères. La solution suit également les alertes de sécurité (dont la liste de référence est ici) et les positionne dans la matrice de MITRE ATT&CK.

Appliquer de la gouvernance sur les clusters Kubernetes

La gouvernance fait référence à la capacité pour des équipes d’administration de vérifier et forcer certaines règles de configuration (dont certaines dédiées à l’amélioration de la sécurité) à l’échelle de groupes, département ou d’organisation. Ici le but est de gérer à l’échelle le suivi voire l’imposition de règles s’appliquant à des clusters Kubernetes.

Un petit article de blog de la Cloud Native Computing Foundation résumant tout cela : Kubernetes governance, what you should know https://www.cncf.io/blog/2020/05/29/kubernetes-governance-what-you-should-know/

Azure Policy est un service PaaS Azure qui aide à appliquer les normes organisationnelles et à évaluer la conformité à l’échelle. Pour cela Azure Policy propose un ensemble de règles prêtes à l’emploi (appelées définitions) qu’il est possible de personnaliser et/ou regrouper dans des initiatives qu’on applique ensuite sur des management groups, subscriptions, resource groups ou des ressources.

Azure Policy peut être utilisé sur des clusters AKS ou Azure Arc enabled Kubernetes et propose un ensemble de définitions prêtes à l’emploi et spécifiques à Kubernetes.

La liste des Azure Policy built-in definitions est disponible à l’adresse suivante : https://docs.microsoft.com/en-us/azure/aks/policy-reference

Techniquement, Azure Policy enrichi Gatekeeper v3, un admission controller webhook pour Open Policy Agent (OPA), pour appliquer à l’échelle des contrôles et des mises en vigueur sur les clusters d’une manière centralisée et cohérente.

Pods identities

Azure Active Directory pod-managed identities permet de créer des identités (dans Azure AD) et de les associer à des pods Kubernetes. Ainsi il devient plus aisé et plus sécurisé de donner l’accès à des ressources Azure via l’Identity and Access Management.

Cette fonctionnalité actuellement en preview va être remplacée par une nouvelle implémentation baptisée pod-managed identities V2 aussi en preview (mais pas encore documentée).

Du coup, gardez ça en tête mais attendez un peu plus d’informations sur la v2.

La documentation de la v1 est ici : https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity

— Stanislas Quastana —