L’API Server de Kubernetes est un composant essentiel car tous les ordres de lecture, création, modification ou suppression des objects Kubernetes passent par là. Il faut donc apporter une attention particulière à sa sécurisation.

Dans Azure Kubernetes Services, l’API Server est par défaut exposée sur un endpoint public. Cela ne signifie pas pour autant qu’il est en mode “Open Bar” et il est tout à faire possible et recommandé de durcir cette configuration par différents paramétrages.

Limiter la surface d’exposition (sur le réseau)

Ici 2 options :

1. Limiter l’accès à l’API Server à une plage d’adresses IP autorisées

Attention lors de la configuration de cette option à ne pas oublier des IP utilisant l’API Server. Se poser avant LA question “Qui utilise l’API Server ?”

Réponse : Les admin / dev via kubectl ou API REST, les kubelet des noeuds, le Dashboard Kubernetes (instancié de manière optionnelle sous la forme d’un pod dans le cluster), toute application se connectant à l’API server de Kubernetes (Prometheus…)

Les valeurs sont bien entendues modifiables à posteriori.

2.Déployer le cluster en mode privé

Le private cluster AKS est un mode de déploiement où l’API server a une adresse IP privée (dans la RFC1918) et n’est pas exposé sur Internet. La communication entre le control plane et les VM Worker node est faite via le Service Azure Private Link.

L`accès à l’API Server pourra être fait depuis une VM dans Azure (dans le même Virtual Network ou un dans VNet connecté en Peering) ou via une machine connectée via ExpressRoute ou une connexion VPN.

Point important : utiliser le mode private cluster va impliquer des limitations qu’il faut connaitre avant de choisir ce type de déploiement : pas de support des Authorized IP ranges, pas de support des agents Azure DevOps hébergés par Microsoft (considérer l’usage de Self Hosted agents), pas de support du Uptime SLA, impossibilité de convertir un cluster existant en cluster privé…

Activer et utiliser le RBAC de Kubernetes

Le RBAC de Kubernetes est activé par défaut avec AKS en ligne de commande ou via le portail Azure. Il est fortement recommandé de ne pas le désactiver !

Créer dans Kubernetes des rôles spécifiques aux besoins des utilisateurs et des applications et les associer à des sujets (utilisateur, groupe ou ServiceAccounts) au niveau d’un namespace (RoleBinding) ou du cluster (ClusterRoleBinding).

Appliquer ici le principe du moindre privilège : créer des rôles strictement nécessaires aux utilisateurs, groupes ou ServiceAccounts MAIS conserver l’approche Keep It Simple. Créer des dizaines de rôles différents risque rapidement d’être difficile à gérer dans le temps.

Activer l’intégration à Azure Active Directory

Ici le but est de forcer une authentification des requêtes envoyées à l’API Server et de s’appuyer sur le référentiel d’identités de Microsoft (Azure Active Directory) avec l’expérience d’authentification commune aux services Cloud de Microsoft. Pour rappel, Kubernetes n’inclus pas de solution de gestion d’identités même si il est possible de créer des ServiceAccount

Les bénéfices à utiliser Azure Active Directory pour l’authentification des accès à l’API Server sont multiples:

• Limiter le risque lié à la divulgation d’un fichier kubeconfig incluant des tokens.
• Eviter de démultiplier les bases de comptes dans l’organisation. Utiliser un référentiel déjà utilisé pour accéder à des services tels qu’Office 365, Azure, PowerBI…
• Utiliser les mécanismes d’authentification forte d’Azure AD MFA
• Utiliser les mécanismes d’accès conditionnel d’Azure Active Directory
• Auditer et suivre les authentification avec les journaux d’activité d’Azure AD et Azure AD access review

Bref en activant cette authentification, vous protégez l’API Server de la même manière que Microsoft protège les accès à Office 365, Azure, Dynamics365… Le endpoint public n’est donc pas une fatalité !

Historiquement cette intégration était un peu compliquée à mettre en oeuvre. Désormais une nouvelle méthode (baptisée AKS-managed Azure Active Directory integration) simplifie à l’extrême l’opération. Attention cette intégration se fait lors de la création du cluster ou peut être activée sur un cluster AKS déjà configuré avec l’ancienne méthode d’intégration. Une fois l’intégration faite, il n’est pas possible de la désactiver.

Une fois l’intégration Azure AD effectuée, il reste le travail de RBAC de Kubernetes à faire avec l’utilisation dans les bindings des emails (identifiant des utilisateurs Azure AD) ou des Group Object ID (pour les groupes Azure AD)

Une nouvelle option est train d’arriver (encore en preview lors de la rédaction de cet article) l’utilisation du RBAC d’Azure pour gérer les autorisations dans Kubernetes.

Une fois le cluster créé, il est possible d’affecter des rôles RBAC Azure Kubernetes Services à des utilisateurs ou groupes. Il existe quatre rôles pré-définis dans Azure et il est possible de créer également des custom roles.

Utiliser des admissions controllers

Nous venons de traiter deux niveaux de contrôle successifs l‘authentification (avec Azure AD) et les autorisations (avec le RBAC de Kubernetes ou le RBAC d’Azure), il reste une dernière couche de contrôle au niveau de l’API Server : le contrôle des admissions qui va permettre d’ajouter des contrôles supplémetaire avant l’accés à la base de configuration de Kubernetes (dans ETCD généralement)

Un admission controller peut être de type validating (dans ce cas il va valider des choses dans les requêtes envoyées à l’API Server) ou de type mutating (dans ce cas, il va faire des modifications) ou les deux.

Les admission controllers se configurent au niveau de l’API Server (le control plane managé dans le cas d’AKS)

AKS supporte les admission controllers suivants:

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

Cette liste n’est pas modifiable mais il est possible d’utiliser les admissions controllers webhooks (Validating ou Mutating) pour définir ses propres contrôles

Journaliser l’activité de l’API Server (Control Plane d’AKS)

Même si la partie Master Nodes d’un cluster Azure Kubernetes Service n’est pas accessible (car c’est un Control Plane managé), Microsoft permet d’activer la journalisation et de récupérer les logs du control plane et plus précisément :

• kube-apiserver
• kube-audit
• kube-audit-admin
• kube-controller-manager
• kube-scheduler
• cluster-autoscaler
• guard
• AllMetrics

Ces logs peuvent être stockés dans un compte de stockage Azure, un Azure Workspace Log Analytics ou streamés vers un Event Hub pour traitement vers un système externe.

Si les logs sont envoyés dans le puit de logs Azure Workspace Analytics, alors il est possible de faire des requêtes en langage Kusto Query Language pour rechercher l’information. A noter que cet Azure Workspace Log Analytics peut aussi servir à un SIEM tel que Azure Sentinel.

— Stanislas —