AKS — Azure Kubernetes Service: architecture, sécurité et hardening

⏱️

Temps de lecture estimé
~18 minutes

Cet article fait partie de la série Kubernetes Managé & Edge. Si tu cherches le guide de choix et le tableau comparatif global, commence par là.

AKS est souvent sous-estimé par les équipes qui ne vivent pas dans l’écosystème Microsoft. Pourtant, depuis 2024, l’intégration entre Kubernetes et Azure s’est considérablement approfondie : AKS Automatic, Karpenter natif, Istio en add-on managé, et Defender for Containers qui monitore en continu. Si votre organisation est Azure-first, AKS est aujourd’hui la solution Kubernetes la mieux intégrée dans son écosystème.

Le point aveugle le plus courant sur AKS : confondre les permissions Azure RBAC (qui donnent accès au cluster) avec les permissions Kubernetes RBAC (qui définissent ce qu’on peut faire dans le cluster). Ces deux couches sont indépendantes, et les gérer séparément est une source de failles récurrente.

Architecture AKS — Ce que Microsoft gère, ce que vous gérez

Plan de contrôle managé (Microsoft)

Microsoft gère entièrement le plan de contrôle AKS :

kube-apiserver multi-instances avec load balancer
etcd répliqué en zone géographique
kube-controller-manager et kube-scheduler
Certificats et rotation automatique
Mises à jour de sécurité du plan de contrôle

Le plan de contrôle AKS est gratuit — vous payez uniquement les nodes workers (VMSS).

Node pools — VMSS sous le capot

Les nodes AKS sont des machines virtuelles Azure organisées en Virtual Machine Scale Sets (VMSS). Chaque node pool peut avoir :

Un OS différent (Ubuntu Linux, Azure Linux, Windows Server)
Une taille de VM différente (Standard_D2s_v5, Standard_NC6s_v3 pour GPU, etc.)
Des taints et labels pour le scheduling sélectif
Des politiques de mise à l’échelle indépendantes

AKS Automatic vs AKS Standard

Depuis fin 2024, AKS propose deux modes distincts :

Aspect	AKS Standard	AKS Automatic
Gestion des nodes	Manuelle (node pools)	Automatique (Karpenter)
Sécurité par défaut	À configurer	Restrictive par défaut
Contrôle	Total	Limité aux workloads
Cas d’usage	Équipes ops expérimentées	Équipes dev-focused
Pod Security Standards	À configurer	`baseline` enforced
Image integrity	Optionnel	Activé par défaut

En AKS Automatic, Microsoft prend en charge le provisionnement des nodes via Karpenter, enforce les Pod Security Standards au niveau baseline, et active Image Integrity par défaut. Ce mode est recommandé pour les équipes qui ne sont pas expérimentées avec la gestion de l’infrastructure Kubernetes et/ou qui veulent se concentrer sur les workloads sans gérer l’infrastructure.

Identité et accès — La couche la plus complexe(ou pas) d’AKS

Les deux couches RBAC

C’est le point de confusion numéro 1 sur AKS. Il existe deux systèmes de contrôle d’accès indépendants :

Azure RBAC (niveau Azure Resource Manager) :

Contrôle qui peut interagir avec le cluster via az aks ou Azure Portal
Rôles : Azure Kubernetes Service Cluster Admin Role, Azure Kubernetes Service RBAC Reader, etc.
Géré via Azure IAM, Microsoft Entra ID

Kubernetes RBAC (niveau cluster) :

Contrôle ce qu’on peut faire DANS le cluster (kubectl)
Roles, ClusterRoles, RoleBindings, ClusterRoleBindings standards Kubernetes
Peut être enrichi avec des identités Microsoft Entra ID via Azure AD integration

Azure Workload Identity — Le standard moderne

L’ancien AAD Pod Identity est déprécié. Azure Workload Identity est le pattern à adopter. Il utilise OIDC pour permettre à un pod d’obtenir des tokens Azure AD sans gérer de secrets statiques.

Fonctionnement :

Le pod présente son ServiceAccount token Kubernetes à Azure AD
Azure AD valide le token via l’OIDC Issuer URL du cluster AKS
Azure AD retourne un token avec les permissions de la Managed Identity associée
Le pod utilise ce token pour accéder aux services Azure (Key Vault, Storage, etc.)

Vecteurs d’attaque courants

Exfiltration de tokens statiques : un attaquant avec accès à kubectl peut copier un ServiceAccount token depuis les secrets Kubernetes et l’utiliser pour accéder aux services Azure si ce token est associé à une Managed Identity avec des permissions élevées.
Élévation via Azure RBAC : un compte Azure compromis avec des permissions sur le cluster (ex: Azure Kubernetes Service Cluster Admin Role) peut obtenir un kubeconfig avec accès cluster-admin, contournant ainsi les contrôles d’accès Kubernetes.
Accès aux metadata Azure : un pod compromis peut tenter d’accéder à l’endpoint de metadata Azure pour obtenir des tokens d’identité d’instance ou d’autres informations sensibles. Defender for Containers peut détecter ce comportement.
Utilisation abusive de l’API Kubernetes : un attaquant avec accès au cluster peut créer des ServiceAccounts, ClusterRoleBindings, ou modifier les permissions pour escalader ses privilèges ou maintenir un accès persistant.

Avantages de Workload Identity

Zéro secret statique à gérer
Tokens de courte durée (dépendant de la configuration du cluster….), non copiables
Intégration native avec Azure AD et les services Azure
Meilleure sécurité et observabilité (Defender for Containers peut détecter les tentatives d’accès aux metadata Azure ou les comportements anormaux liés à l’authentification)
Recommandé par Microsoft pour tous les nouveaux clusters AKS
Permet de suivre le principe du moindre privilège en associant des permissions Azure spécifiques à chaque workload via des Managed Identities dédiées
Facilite la rotation des permissions et la révocation d’accès en cas de compromission (il suffit de révoquer la Managed Identity ou de modifier ses permissions dans Azure AD)
Supporté à la fois en AKS Standard et AKS Automatic, mais activé par défaut en Automatic pour renforcer la sécurité dès le départ
Permet d’éviter les risques liés aux tokens statiques, comme l’exfiltration ou la réutilisation par des attaquants, en fournissant des tokens dynamiques et éphémères via OIDC
Améliore la visibilité et le monitoring des accès aux services Azure depuis les workloads Kubernetes, notamment grâce à l’intégration avec Defender for Containers qui peut détecter les comportements suspects liés à l’authentification et à l’accès aux ressources Azure

Réseau AKS — Azure CNI, Overlay et Cilium

Les options réseau d’AKS sont un sujet complexe, avec des implications directes sur la sécurité, les performances et la scalabilité du cluster. Pour cela il est possible de se baser sur le réseau Azure CNI classique, qui attribue une IP Azure à chaque pod. Cependant, ce mode peut rapidement épuiser les adresses IP disponibles dans le subnet Azure, surtout pour les gros clusters …voir couteuses en termes de gestion d’adressage IP. C’est pourquoi Microsoft recommande désormais le mode Azure CNI Overlay, qui utilise un espace d’adressage privé pour les pods, résolvant ainsi le problème d’épuisement des IPs tout en conservant les performances du CNI Azure.

Les trois options CNI

Azure CNI (mode classique) : chaque pod reçoit une IP du subnet Azure. Simple, performant, mais consomme beaucoup d’adresses IP (peut épuiser un subnet sur les gros clusters). Et chacune des IP vous coûtera en termes de gestion et de planification d’adressage.

Azure CNI Overlay (recommandé pour les nouveaux clusters) : les pods utilisent un espace d’adressage privé (overlay) distinct du subnet Azure. Résout le problème d’épuisement des IPs tout en conservant les performances du CNI Azure. C’est la configuration recommandée pour la plupart des clusters AKS, surtout ceux de taille moyenne à grande.

Azure CNI + Cilium (option avancée) : combine Azure CNI Overlay avec Cilium comme data plane réseau. Cilium apporte eBPF(vous savez ce qui vous permet de faire des filtrages et des observabilités avancées au niveau du kernel) pour des fonctionnalités avancées de sécurité réseau, d’observabilité L7, et de NetworkPolicies plus puissantes. Recommandé pour les clusters nécessitant une sécurité réseau renforcée ou une observabilité approfondie. Mais attention, cette configuration est plus complexe à gérer et peut introduire des problèmes de compatibilité avec certains services Azure.

Azure Policy et OPA/Gatekeeper

Azure Policy pour AKS utilise OPA/Gatekeeper en coulisses. C’est l’add-on le plus important à activer pour enforcer des politiques de sécurité cluster-wide.

OPA/Gatekeeper permet de définir des Constraint Templates personnalisées en Rego(j’avoue le langage peut être un peu déroutant au début et on peut se poser la question de pourquoi on utilise pas du YAML directement….mais bon…), et de les appliquer via des Constraints sur des ressources Kubernetes spécifiques (pods, deployments, services, etc.). C’est un moyen puissant d’appliquer des règles de sécurité, de conformité, ou même des règles métier spécifiques à votre organisation.

Il est crucial d’activer Azure Policy dès le provisionnement du cluster. L’ajout rétroactif de policies sur un cluster existant peut entraîner des incidents massifs, car les policies s’appliqueront immédiatement à tous les workloads non conformes déjà déployés et la…. vous vous retrouverez avec des pods qui ne démarrent plus, des déploiements qui échouent, et une avalanche d’alertes dans Defender for Containers. En activant Azure Policy dès le départ, vous pouvez construire votre cluster avec les bonnes pratiques de sécurité intégrées, évitant ainsi les incidents liés à des workloads non conformes !!!

Voici une liste des Policies intégrées recommandées et leur description

Azure propose une bibliothèque de policies prêtes à l’emploi. Voici celles que j’active systématiquement :

Policy	Description
`K8sPSPPrivilegedContainer`	Bloque les containers privilégiés
`K8sPSPHostNetworkingPorts`	Bloque l’accès au réseau hôte
`K8sPSPCapabilities`	Limite les Linux capabilities
`K8sContainerLimits`	Force les resource limits sur les containers
`K8sBlockNodePortServices`	Bloque les Services NodePort
`K8sImageDigest`	Force l’utilisation de digests d’images (pas de tags mutables)

Constraint Template personnalisé

Pour des règles métier spécifiques, vous pouvez écrire vos propres Constraint Templates en yaml(et pourquoi pas en Rego hein ? ca serait trop simple…). Par exemple, pour forcer un label “owner” sur tous les deployments :

# Forcer un label "owner" sur tous les deployments
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          properties:
            labels:
              type: array
              items: {type: string}
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        violation[{"msg": msg}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("Labels manquants: %v", [missing])
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-owner-label
spec:
  match:
    kinds:
    - apiGroups: ["apps"]
      kinds: ["Deployment"]
  parameters:
    labels: ["owner", "env"]

Microsoft Defender for Containers

Defender for Containers est l’outil de sécurité runtime d’Azure pour AKS (mais pas que). Il apporte trois capacités clés :

1. Vulnerability Assessment : scanne les images dans ACR et les images en cours d’exécution, détecte les CVEs, et produit des rapports dans Microsoft Defender for Cloud.

2. Runtime Threat Detection : surveille les comportements anormaux via un agent DaemonSet sur les nodes. Il détecte notamment :

Exécution de shells dans les containers
Accès aux metadata Azure depuis les pods
Tentatives de privilege escalation
Communication vers des IP de Command & Control connues

3. Kubernetes API Auditing : analyse les appels à l’API Kubernetes en temps réel pour détecter les comportements suspects (création de ClusterRoleBindings anormaux, accès aux secrets, etc.).

A vous ensuite de configurer des alertes dans Microsoft Defender for Cloud pour être notifié en cas de détection d’une menace. De mettre en place une gestion centralisée de ces alertes et de les intégrer dans votre processus d’incident response. Il y a d’autres possibilité d’intégration d’autres outils de sécurité pour faire la meme chose, mais cela n’est pas l’objet de cet article…. On ne va parler que des outils natifs Azure pour AKS, parceque on est pas sur que vous ayez du budget pour des outils tiers, et que les outils natifs sont déjà pas trop dégeu en termes de fonctionnalités et d’intégration avec l’écosystème Azure.

Image Integrity — Signer et vérifier les images

AKS supporte Image Integrity basé sur Notation (successeur de Notary). C’est l’équivalent de Binary Authorization de GKE, adapté à l’écosystème Azure. Cela vous permet de signer cryptographiquement vos images Docker et de configurer le cluster pour n’exécuter que des images signées par vos autorités de confiance (c’est top cela, ca permet de renforcer votre combat contre les Attaques de la chaine d’approvisionnement . Coucou

Exemple de configuration pour activer Image Integrity et forcer les images signées :

# Activer Image Integrity sur le cluster
az aks update \
  --resource-group mon-rg \
  --name mon-cluster \
  --enable-image-integrity

# Configurer une policy via Azure Policy
# La policy "Kubernetes clusters should use only signed images"
# peut être assignée au niveau abonnement ou resource group
az policy assignment create \
  --name "signed-images-only" \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/<policy-id>" \
  --scope "/subscriptions/<sub-id>/resourceGroups/<rg>"

Monitoring et observabilité

Le montoring et l’observabilité sont des éléments clés pour la sécurité et la gestion d’un cluster AKS(et aussi d’autres éléments mais le débat n’est pas la). Microsoft propose plusieurs outils intégrés, mais le plus complet est Azure Monitor(bah oui on va pas préconisé un truc pas Microsoft….) avec l’add-on Container Insights.

Azure Monitor + Container Insights

Plusieurs options de monitoring sont disponibles pour AKS, mais la plus intégrée est Azure Monitor avec l’add-on Container Insights. Cela vous permet de collecter des métriques, logs et events Kubernetes directement dans Azure Monitor, avec des dashboards préconfigurés et des alertes basées sur les données du cluster.

# Activer Container Insights
az aks enable-addons \
  --addons monitoring \
  --name mon-cluster \
  --resource-group mon-rg \
  --workspace-resource-id /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/<workspace>

Container Insights collecte automatiquement :

Les Métriques CPU/mémoire des nodes et pods
Les Logs des containers (stdout/stderr)
Les Events Kubernetes
Les Données de performance des nodes

D’autres éléments peuvent aussi être collectés si vous en avez besoin. L’avantage d’Azure Monitor est l’intégration native avec les autres services Azure, la possibilité de créer des alertes basées sur les données du cluster, et la centralisation du monitoring pour tous vos services Azure. (mais bon, cela peut aussi être un inconvénient si vous préférez des outils open-source comme Prometheus/Grafana, ou si vous avez déjà une stack de monitoring en place).

Prometheus managé avec Azure Monitor

Pour les équipes qui utilisent Prometheus/Grafana, Azure Monitor propose une option de Prometheus managé. Cela vous permet de collecter les métriques Prometheus depuis vos workloads Kubernetes et de les stocker dans Azure Monitor(et oui….comment vous vendre du SaaS….), tout en continuant à utiliser Grafana pour la visualisation.

# Activer Azure Monitor managed Prometheus
az aks update \
  --resource-group mon-rg \
  --name mon-cluster \
  --enable-azure-monitor-metrics \
  --azure-monitor-workspace-resource-id <workspace-id> \
  --grafana-resource-id <grafana-id>

Exemple concret de Confusion RBAC Azure/Kubernetes

Voici une situation potentiellement réelle qui illustre les risques liés à la confusion entre Azure RBAC et Kubernetes RBAC sur AKS.

Contexte : Une équipe de développement accède à un cluster AKS via Azure AD. Un développeur senior a le rôle Azure Azure Kubernetes Service Cluster Admin Role sur le resource group (oui on sait , saismal)

Scénario d’attaque :

Le développeur utilise az aks get-credentials --admin pour obtenir un kubeconfig cluster-admin.
Avec ce kubeconfig, il inspecte les secrets de tous les namespaces (y compris kube-system).
Il découvre un ServiceAccount avec des permissions cluster-admin utilisé par un outil CI/CD.
Il copie le token de ce ServiceAccount dans un outil externe pour automatiser des déploiements en dehors du pipeline CI/CD officiel.
Plusieurs semaines plus tard, le compte Azure du développeur est compromis par phishing. L’attaquant utilise le token copié (non révoqué) pour accéder au cluster en contournant Azure AD.

Ce qui aurait évité cette attaque :

Interdire --admin kubeconfig en production ; forcer l’authentification Azure AD sur le cluster
Rotation régulière des ServiceAccount tokens (TTL courts avec kubectl create token --duration=1h)
Alertes Defender for Containers sur la copie/extraction de secrets
Principe du moindre privilège : le développeur n’avait pas besoin de Cluster Admin Role
Utiliser Workload Identity (tokens de courte durée, non copiables) plutôt que des ServiceAccount tokens statiques

Quelques références pour aller plus loin

✓ À retenir 📌

✓ Azure RBAC ≠ Kubernetes RBAC : deux systèmes indépendants. Un utilisateur peut avoir des droits Azure sur le cluster sans droits Kubernetes (et vice-versa). Audite les deux couches séparément.

✓ Azure Workload Identity est le seul pattern acceptable pour les pods qui accèdent aux services Azure. Les ServiceAccount tokens statiques, les secrets dans les Variables d'environnement, les Managed Identity d'instance — tout ça c'est du passé.

✓ Azure CNI Overlay + Cilium est la combinaison optimale : Overlay résout l'épuisement des IPs, Cilium apporte eBPF, NetworkPolicies avancées et observabilité L7.

✓ Active Azure Policy dès le provisionnement — pas après. Les policies se retrouver appliquées rétroactivement sur des workloads existants non conformes, ce qui génère des incidents.

✓ Defender for Containers monitore en runtime : des comportements comme "shell dans un container en production" ou "accès aux metadata Azure depuis un pod" sont détectés en temps réel. Active-le systématiquement.

AKS