Depuis le 1er juillet 2026, Microsoft facture la protection des conteneurs serverless sur Azure Container Apps et Azure Container Instances. Cette bascule marque un tournant simple à comprendre : un service longtemps traité comme une boîte noire gérée par Microsoft entre enfin dans le périmètre d’audit classique des équipes sécurité. Ce tutoriel vous montre comment activer Microsoft Defender for Cloud sur un environnement Azure Container Apps, configurer l’analyse de vulnérabilités, mettre en place le contrôle d’admission Kubernetes et éviter les pièges de facturation qui surprennent la plupart des équipes au premier mois.
Le format est pensé pour un ingénieur cloud ou un responsable sécurité qui gère déjà un abonnement Azure et veut passer d’un déploiement non surveillé à une posture de sécurité mesurable. Comptez environ 90 minutes pour suivre l’ensemble des 13 étapes, avec une pause de 15 minutes pendant que l’analyse initiale des images tourne en arrière-plan.
Pourquoi cela compte particulièrement pour les équipes en Europe
Pour une entreprise basée en France ou ailleurs dans l’Union européenne, cette bascule de facturation n’est pas qu’une ligne de budget cloud à surveiller. La directive NIS2 impose déjà des obligations de gestion des risques aux opérateurs de services essentiels et importants, avec des sanctions qui peuvent grimper jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires mondial selon le texte transposé. Un conteneur serverless mal configuré, exposé sans limite réseau ni analyse de vulnérabilités, entre pleinement dans le périmètre que ces textes visent à réduire.
Le Cyber Resilience Act ajoute une couche supplémentaire pour les éditeurs qui distribuent du code packagé en conteneurs. Démontrer qu’un processus d’analyse de vulnérabilités tourne en continu sur vos images, plutôt qu’un contrôle ponctuel avant mise en production, devient un argument concret face à un auditeur ou un client qui exige des garanties contractuelles. Ce tutoriel ne remplace aucune certification réglementaire, mais il pose une base technique vérifiable que vous pourrez citer dans un dossier de conformité.
Prérequis : outils, versions et accès nécessaires
Avant de commencer, vérifiez que vous disposez des éléments suivants. Un abonnement Azure actif avec le rôle Contributeur ou Propriétaire sur le groupe de ressources ciblé. Azure CLI en version 2.75 ou supérieure, installable via az upgrade si une version plus ancienne traîne sur votre poste. L’extension Container Apps pour Azure CLI, ajoutée avec az extension add --name containerapp. Un registre de conteneurs, Azure Container Registry ou un registre tiers compatible OCI, contenant au moins une image à analyser. Enfin, un accès au portail Azure avec les droits nécessaires pour activer des plans payants sur Microsoft Defender for Cloud, car cette opération touche la facturation de l’abonnement entier.
Prévoyez aussi un environnement Container Apps existant ou soyez prêt à en créer un à l’étape 2. Si vous testez sur un abonnement de démonstration, isolez-le dans un groupe de ressources dédié pour ne pas fausser vos futurs rapports de coûts.
Étape 1 : comprendre l’architecture serverless d’Azure Container Apps
Azure Container Apps repose sur Kubernetes en coulisses, mais Microsoft masque le plan de contrôle à l’utilisateur. Vous ne gérez ni nœuds, ni certificats d’API server, ni kubelet. Cette abstraction réduit la charge opérationnelle, mais elle déplace aussi la question de la sécurité : vous ne pouvez plus durcir le cluster vous-même, vous dépendez des contrôles que Microsoft expose côté plateforme. C’est exactement ce que couvre Microsoft Defender for Cloud depuis l’extension de sa couverture serverless, documentée dans les notes de version officielles de Defender for Cloud.
Deux surfaces comptent ici. La première est l’image de conteneur elle-même, stockée dans un registre et scannée pour des vulnérabilités connues. La seconde est la configuration d’exécution, c’est-à-dire les ressources CPU allouées, les règles de scaling, l’exposition réseau et les secrets injectés en variables d’environnement. Un audit de sécurité sérieux couvre les deux, pas uniquement l’image.
Modèle de responsabilité partagée : qui sécurise quoi
Comme pour tout service cloud géré, la sécurité d’Azure Container Apps se répartit entre Microsoft et vous, et confondre les deux côtés mène directement aux pièges décrits plus bas dans cet article. Microsoft prend en charge la sécurité du plan de contrôle Kubernetes sous-jacent, l’isolation entre locataires, le correctif des composants d’infrastructure et la disponibilité du service. Votre équipe reste seule responsable du contenu de vos images, des dépendances logicielles qu’elles embarquent, des secrets stockés en variables d’environnement et des règles réseau que vous définissez vous-même sur l’ingress.
Defender for Cloud ne change rien à ce découpage. Il ajoute simplement un outil de visibilité sur la partie qui vous incombe. Une image contenant une bibliothèque vulnérable reste votre problème même si elle tourne sur une plateforme entièrement gérée par Microsoft. C’est précisément ce que l’étape 6 va rendre visible, souvent pour la première fois sur des applications déployées depuis des mois sans analyse systématique.
Étape 2 : créer l’environnement Container Apps et déployer une image de test
Si vous partez de zéro, créez d’abord un environnement puis une application de test. Cette base vous servira de terrain pour valider chaque contrôle de sécurité sans toucher à un workload de production.
az group create --name rg-secure-aca --location westeurope
az containerapp env create \
--name env-secure-aca \
--resource-group rg-secure-aca \
--location westeurope
az containerapp create \
--name aca-demo-app \
--resource-group rg-secure-aca \
--environment env-secure-aca \
--image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest \
--target-port 80 \
--ingress external \
--min-replicas 1 \
--max-replicas 3Vérifiez le déploiement avec az containerapp show --name aca-demo-app --resource-group rg-secure-aca --query properties.configuration.ingress.fqdn. Vous devez obtenir une URL en .azurecontainerapps.io accessible en HTTPS. Si la commande renvoie une erreur de quota, c’est le signe que votre abonnement n’a pas encore de capacité Container Apps provisionnée dans la région choisie, un problème courant sur les abonnements d’essai.
Étape 3 : activer Microsoft Defender for Cloud sur l’abonnement
Defender for Cloud propose un socle gratuit, le Foundational CSPM, activé automatiquement sur tout abonnement Azure. Il donne une visibilité basique mais ne couvre ni l’analyse d’images ni la détection de menaces en temps réel. Pour aller plus loin, vous devez activer un plan payant au niveau de l’abonnement.
az security pricing create \
--name CloudPosture \
--tier Standard
az security pricing create \
--name Containers \
--tier StandardLa première commande active Defender CSPM, la seconde active Defender for Containers. Les deux travaillent ensemble : CSPM évalue la posture globale de configuration, Containers s’occupe de l’analyse d’images et de la détection d’exécution. Activer l’un sans l’autre laisse un angle mort, soit sur la configuration, soit sur le contenu des images.
Étape 4 : activer la protection des conteneurs serverless
C’est ici que l’article prend tout son sens. Depuis le 1er juillet 2026, la découverte et l’évaluation de posture pour les workloads conteneurisés serverless sont généralement disponibles, selon les notes de version de Defender for Cloud. Concrètement, cela signifie qu’Azure Container Apps et Azure Container Instances sont désormais couverts au même titre que les clusters AKS classiques, mais sous une bascule de facturation séparée qu’il faut activer explicitement.
az security setting update \
--name "MCAS" \
--enabled true
# Activation specifique de la protection serverless
# via le portail Azure : Defender for Cloud > Parametres d'environnement
# > selectionner l'abonnement > Defender CSPM > Parametres
# > activer "Serverless containers protection"Cette étape ne se fait pas entièrement en CLI à l’heure actuelle, une partie de l’activation reste au portail. Ne sautez pas cette étape en pensant que la simple présence d’une ressource Container Apps déclenche la protection automatiquement. D’après la documentation officielle sur le CSPM, la fonctionnalité doit être activée manuellement pour commencer à produire des résultats, et c’est aussi à ce moment que la facturation associée démarre.
Étape 5 : configurer l’accès au registre de conteneurs
Pour que Defender for Cloud analyse vos images, il a besoin d’un accès en lecture au registre. Sur Azure Container Registry, l’intégration se fait automatiquement si le registre est dans le même tenant. Sur un registre tiers, vous devez configurer explicitement les identifiants.
az acr update --name monregistreacr --admin-enabled true
az role assignment create \
--assignee "<object-id-defender>" \
--role "AcrPull" \
--scope "/subscriptions/<sub-id>/resourceGroups/rg-secure-aca/providers/Microsoft.ContainerRegistry/registries/monregistreacr"Sans cet accès, Defender for Cloud ne verra que les métadonnées de déploiement, pas le contenu des couches d’image. Vous obtiendrez alors des alertes de posture mais aucune alerte de vulnérabilité logicielle, ce qui donne une fausse impression de sécurité.
Étape 6 : lancer une analyse de vulnérabilités sur vos images
Une fois l’accès configuré, l’analyse démarre automatiquement à chaque nouveau push d’image, puis se répète périodiquement sur les images déjà déployées. Pour forcer une première analyse sans attendre le cycle automatique, déclenchez un nouveau déploiement de test.
az containerapp update \
--name aca-demo-app \
--resource-group rg-secure-aca \
--image monregistreacr.azurecr.io/demo-app:v2Les résultats apparaissent dans Defender for Cloud sous Recommandations, généralement entre 15 et 40 minutes après le déploiement selon la taille de l’image. Un résultat typique ressemble à ceci :
Recommandation : Les images de conteneur doivent avoir les resultats
de vulnerabilite resolus
Ressource affectee : aca-demo-app
Severite : Elevee (3), Moyenne (11), Faible (7)
CVE les plus critiques : CVE-2025-XXXX (bibliotheque OpenSSL obsolete)
Etat : Action requiseSi la section reste vide après une heure, reprenez l’étape 5 : dans l’immense majorité des cas, c’est un problème de permission sur le registre, pas un délai d’analyse anormalement long.
Étape 7 : mettre en place le contrôle d’admission Kubernetes
Le contrôle d’admission des mauvaises configurations Kubernetes est passé en disponibilité générale en 2026 selon les notes de version de Defender for Cloud. Cette fonctionnalité évalue la configuration d’une ressource au moment même de sa création, avant qu’un pod ou un déploiement non conforme n’entre réellement en service. C’est une différence fondamentale par rapport à l’analyse de posture classique, qui détecte un problème après coup, parfois des heures après qu’il a été exposé.
Pour l’activer sur un cluster géré compatible, le paramètre se trouve dans Defender for Cloud sous Environment settings, puis Defender for Containers, puis Kubernetes admission control enforcement. Le portail reste à ce jour le chemin le plus fiable pour cette configuration, la couverture CLI étant encore partielle sur ce point précis.
Étape 8 : choisir entre mode audit et mode blocage
Deux modes sont disponibles. Le mode audit journalise les violations sans empêcher le déploiement, utile pour mesurer l’impact réel avant d’imposer des règles strictes. Le mode blocage refuse purement et simplement la création de la ressource non conforme.
La bonne pratique consiste à démarrer systématiquement en audit pendant deux à quatre semaines. Cela laisse le temps de repérer les faux positifs et les workloads legacy qui ne respecteraient pas une politique stricte dès le premier jour. Beaucoup d’équipes activent le blocage directement et se retrouvent avec des déploiements bloqués en pleine astreinte, un incident évitable avec cette simple précaution.
Étape 9 : appliquer les recommandations de sécurité
L’extension multicloud de Defender for Cloud en 2026 a ajouté environ 90 nouveaux types de ressources et plus de 200 recommandations de sécurité couvrant les données, les identités, le réseau, le calcul et les conteneurs, à la fois sur Azure, AWS et Google Cloud. Pour un environnement Container Apps, les recommandations les plus fréquentes concernent l’exposition réseau non restreinte, l’absence de limites CPU et mémoire explicites, et l’usage de l’image latest plutôt qu’un tag versionné immuable.
Triez ces recommandations par score de sécurisation avant de les traiter une par une. Le score global de Defender for Cloud pondère chaque recommandation selon son impact réel, ce qui évite de passer une journée entière sur un correctif à faible valeur pendant qu’une faille critique reste ouverte. Sur un environnement de taille moyenne, comptez généralement entre 20 et 50 recommandations actives au premier scan, un volume qui redescend fortement après la première vague de correctifs puisque beaucoup de recommandations partagent la même cause racine, comme une politique réseau par défaut trop permissive appliquée à l’ensemble des applications.
Un réflexe utile consiste à regrouper les recommandations par ressource plutôt que par type de problème. Une application qui cumule cinq recommandations distinctes révèle souvent une erreur de configuration initiale plus large qu’un correctif isolé ne résoudra pas durablement, par exemple un modèle de déploiement copié tel quel depuis un ancien projet sans adaptation aux standards de sécurité actuels.
Étape 10 : automatiser la remédiation avec Azure Policy
Corriger manuellement chaque recommandation ne tient pas la charge au-delà de quelques applications. Azure Policy permet d’imposer des règles par défaut sur tout nouveau déploiement dans le groupe de ressources.
az policy assignment create \
--name "deny-latest-tag-aca" \
--display-name "Interdire le tag latest sur Container Apps" \
--policy "/providers/Microsoft.Authorization/policyDefinitions/<id-politique>" \
--scope "/subscriptions/<sub-id>/resourceGroups/rg-secure-aca"Combinez cette politique avec le mode audit du contrôle d’admission vu à l’étape 8. Vous obtenez alors deux filets de sécurité complémentaires, l’un au niveau de l’API Azure Resource Manager, l’autre au niveau de l’admission Kubernetes sous-jacente.
Étape 11 : surveiller les menaces en temps réel
Au-delà de la posture statique, Defender for Containers surveille aussi les comportements anormaux à l’exécution : exécution de binaires inattendus, connexions réseau sortantes vers des adresses suspectes, ou tentatives d’élévation de privilèges dans le conteneur. Ces alertes remontent dans le même tableau de bord que les recommandations de posture, mais avec un niveau de sévérité distinct.
Connectez ce flux à votre outil SIEM existant via Microsoft Sentinel ou un connecteur Log Analytics tiers. Sans cette connexion, les alertes restent cantonnées au portail Azure et un analyste doit s’y connecter manuellement pour les voir, ce qui retarde mécaniquement la détection.
Étape 12 : étendre la couverture au multicloud
Si votre organisation fait tourner des workloads conteneurisés sur Amazon EKS ou Google Kubernetes Engine en parallèle d’Azure Container Apps, Defender for Cloud peut connecter ces comptes pour une vue unifiée. L’analyse d’images à l’exécution fonctionne aussi sur EKS et GKE depuis l’extension multicloud 2026. Pour une comparaison détaillée des coûts de maintien à jour d’un cluster EKS, consultez notre analyse sur la fin de vie de Kubernetes 1.34, qui chiffre l’impact financier d’un cluster laissé en version non supportée.
Pour l’activation multicloud, connectez le compte AWS ou le projet GCP via Environment settings puis Add environment. Le processus demande la création d’un rôle IAM côté AWS ou d’un compte de service côté GCP, avec des permissions en lecture seule suffisantes pour la découverte initiale.
Étape 13 : vérifier et documenter votre posture de sécurité
Dernière étape avant de considérer le travail terminé : exportez un instantané de votre score de sécurisation et archivez-le. Cela sert de référence pour mesurer la progression dans le temps et pour répondre rapidement à un auditeur externe.
az security secure-scores list --query "[].{name:displayName, score:score.current, max:score.max}"Un score sain pour un environnement Container Apps fraîchement sécurisé tourne généralement entre 60 et 75 sur 100 après avoir suivi les 12 premières étapes. Un score sous 40 signale qu’une recommandation critique reste ignorée, souvent liée à l’étape 5 sur l’accès au registre.
Projet complet : du déploiement à la protection bout en bout
Voici l’enchaînement complet, condensé, pour reproduire ce tutoriel sur un environnement neuf en une seule session. Il reprend chaque commande utilisée plus haut dans l’ordre d’exécution réel.
# 1. Infrastructure de base
az group create --name rg-secure-aca --location westeurope
az containerapp env create --name env-secure-aca --resource-group rg-secure-aca --location westeurope
az containerapp create --name aca-demo-app --resource-group rg-secure-aca --environment env-secure-aca \
--image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest --target-port 80 --ingress external
# 2. Activation Defender for Cloud
az security pricing create --name CloudPosture --tier Standard
az security pricing create --name Containers --tier Standard
# 3. Acces registre (a adapter avec vos identifiants reels)
az acr update --name monregistreacr --admin-enabled true
# 4. Verification finale
az security secure-scores list --query "[].{name:displayName, score:score.current}"Ce squelette couvre l’infrastructure, l’activation de la sécurité et la vérification. Le contrôle d’admission Kubernetes et la connexion multicloud, traités aux étapes 7 et 12, restent à finaliser au portail pour l’instant.
Tableau comparatif des tarifs Defender for Cloud
Les tarifs ci-dessous sont des ordres de grandeur publiés par Microsoft et par AWS pour comparaison. Vérifiez toujours le calculateur de prix officiel pour votre région et votre devise avant de budgétiser, car ces chiffres évoluent régulièrement.
| Plan | Fournisseur | Tarif indicatif | Couverture |
|---|---|---|---|
| Defender CSPM | Microsoft Azure | ≈ 5,11 $ / ressource facturable / mois | Posture, conformité, recommandations |
| Defender for Containers | Microsoft Azure | ≈ 0,0095 $ / vCore / heure | Analyse d’images, exécution |
| Serverless protection (Container Apps, ACI) | Microsoft Azure | Facturé depuis le 1er juillet 2026 | Conteneurs serverless |
| Serverless protection (Function Apps, Web Apps) | Microsoft Azure | Facturé depuis le 1er avril 2026 | Fonctions et apps web serverless |
| Security Hub Essentials | AWS | 0,0010 $ à 0,0005 $ / contrôle selon volume | Checks de sécurité, dégressif |
| Ingestion de résultats AWS | AWS | Gratuit jusqu’à 10 000 événements / mois | Findings GuardDuty et tiers |
Le point à retenir : activer Defender CSPM et Defender for Containers sur un environnement Container Apps modeste, avec une poignée de révisions actives, reste généralement dans une fourchette de quelques dizaines de dollars par mois. La facture grimpe surtout avec le nombre de ressources facturables, pas avec le trafic entrant.
Checklist récapitulative des 13 étapes
Gardez ce tableau sous la main pendant votre session de configuration. Il résume chaque étape, l’outil principal utilisé et le temps moyen observé pour la mener à bien.
| Étape | Action | Outil principal | Durée estimée |
|---|---|---|---|
| 1 | Comprendre l’architecture serverless | Lecture, documentation | 5 min |
| 2 | Créer l’environnement et déployer une image test | Azure CLI | 10 min |
| 3 | Activer Defender for Cloud sur l’abonnement | Azure CLI | 5 min |
| 4 | Activer la protection serverless | Portail Azure | 5 min |
| 5 | Configurer l’accès au registre | Azure CLI, IAM | 10 min |
| 6 | Lancer l’analyse de vulnérabilités | Azure CLI, portail | 15 min (attente incluse) |
| 7 | Activer le contrôle d’admission Kubernetes | Portail Azure | 5 min |
| 8 | Choisir le mode audit ou blocage | Portail Azure | 5 min |
| 9 | Appliquer les recommandations prioritaires | Portail Azure | 15 min |
| 10 | Automatiser avec Azure Policy | Azure CLI | 10 min |
| 11 | Connecter la détection de menaces à Sentinel | Microsoft Sentinel | 10 min |
| 12 | Étendre la couverture multicloud | Portail Azure, IAM AWS/GCP | 15 min |
| 13 | Vérifier et archiver le score de sécurisation | Azure CLI | 5 min |
Le total avoisine les 90 minutes annoncées en introduction, à condition de ne pas buter sur un des pièges listés ci-dessous. Une équipe qui suit cette checklist pour la première fois dépasse rarement les deux heures, même en comptant les allers-retours entre CLI et portail.
Erreurs courantes à éviter
- Activer Defender for Containers sans configurer l’accès au registre. Vous payez la fonctionnalité sans obtenir d’analyse de vulnérabilités réelle, puisque Defender ne peut pas lire le contenu des images.
- Passer directement en mode blocage sur le contrôle d’admission. Sans phase d’audit préalable, un déploiement légitime mais non conforme à une règle récente peut être refusé en pleine production.
- Confondre Defender CSPM gratuit et Defender CSPM payant. Le socle gratuit ne couvre pas la protection serverless ni l’analyse d’images, une confusion fréquente qui laisse des workloads non surveillés pendant des mois.
- Oublier de réviser le score de sécurisation après chaque déploiement majeur. Une nouvelle image avec une dépendance obsolète peut faire chuter le score sans que personne ne s’en aperçoive avant le prochain audit trimestriel.
- Ignorer la facturation séparée de la protection serverless. Beaucoup d’équipes activent Defender for Containers en pensant couvrir Container Apps automatiquement, alors que la bascule serverless demande une activation explicite distincte, comme vu à l’étape 4.
Dépannage : problèmes fréquents et solutions
Même en suivant les 13 étapes dans l’ordre, certains comportements inattendus reviennent assez souvent pour mériter une liste dédiée. La plupart de ces symptômes partagent une cause racine commune : une activation partielle, où une commande a réussi mais où une dépendance en amont, souvent une permission IAM, n’a pas suivi. Voici les huit cas les plus fréquemment rencontrés et la correction associée.
- Aucune recommandation n’apparaît après 24 heures. Vérifiez que le plan Defender CSPM est bien en statut Standard et non Free dans Environment settings.
- L’analyse d’image reste bloquée sur « En attente ». Le registre n’accorde probablement pas les droits AcrPull au principal de service de Defender, revenez à l’étape 5.
- Le score de sécurisation n’évolue pas malgré des correctifs appliqués. Le recalcul du score suit un cycle de plusieurs heures, patientez avant de conclure à un échec.
- Le contrôle d’admission bloque un déploiement de CI/CD légitime. Repassez temporairement en mode audit, identifiez la règle fautive dans les logs d’admission, puis ajustez l’exception avant de repasser en blocage.
- La commande
az security pricing createrenvoie une erreur de permission. Le compte utilisé n’a pas le rôle Security Admin ou Contributeur au niveau de l’abonnement, pas seulement du groupe de ressources. - Les alertes de menace n’arrivent jamais dans Sentinel. Le connecteur Microsoft Defender for Cloud doit être activé manuellement côté Sentinel, l’activation de Defender seule ne suffit pas.
- La facture mensuelle dépasse largement l’estimation. Comptez le nombre réel de ressources facturables avec
az security pricing list, un environnement avec de multiples révisions actives par application peut multiplier le compte de ressources sans que ce soit visible au premier coup d’œil. - La connexion multicloud AWS ou GCP échoue à la découverte initiale. Le rôle IAM ou le compte de service créé manque généralement d’une permission de lecture sur les métadonnées de cluster, revérifiez le modèle CloudFormation ou Terraform fourni par Microsoft pour l’onboarding.
Astuces avancées pour aller plus loin
Une fois les 13 étapes posées, quelques ajustements permettent de gagner en maturité. Segmentez vos environnements Container Apps par criticité métier et appliquez des plans Defender différents selon la sensibilité des données traitées, plutôt que d’appliquer un plan uniforme sur tout l’abonnement. Cela réduit la facture sur les environnements de test tout en gardant une couverture maximale en production.
Automatisez aussi l’export du score de sécurisation vers un tableau de bord externe via l’API REST de Defender for Cloud, plutôt que de dépendre d’une vérification manuelle mensuelle. Un script planifié qui interroge az security secure-scores list chaque semaine et pousse le résultat dans Grafana donne une tendance visuelle bien plus parlante qu’un chiffre isolé consulté une fois par trimestre, un sujet que nous détaillons dans notre tutoriel sur Prometheus et Grafana sur Kubernetes.
Enfin, reliez le contrôle d’admission Kubernetes à votre pipeline Azure Policy pour couvrir aussi bien les ressources créées via le portail que celles créées en ligne de commande ou via Terraform. Les deux mécanismes doivent converger vers les mêmes règles, sous peine de créer deux sources de vérité contradictoires.
Mettez aussi en place une alerte de facturation dédiée sur les ressources Defender, séparée de votre alerte de coût cloud générale. Un pic soudain sur la ligne Defender for Containers signale presque toujours une chose : un nouveau déploiement massif d’instances, souvent lié à un test de charge oublié en environnement de staging. Sans cette alerte isolée, le signal se noie dans la facture globale du mois et personne ne le remarque avant la clôture comptable.
Pour les équipes qui gèrent plusieurs dizaines d’applications Container Apps, envisagez un tag de gouvernance appliqué systématiquement à la création, du type criticite=haute ou criticite=basse. Defender for Cloud peut ensuite filtrer ses rapports par tag, ce qui transforme une liste de recommandations génériques en plan d’action priorisé par impact métier réel, plutôt qu’un simple classement par sévérité technique.
Container Apps face à AKS et ACI : quel modèle de sécurité choisir
Toutes les options de conteneurs Azure ne se sécurisent pas de la même façon. Le tableau suivant résume les différences pratiques entre les trois modèles les plus courants, pour vous aider à choisir où placer un workload selon son profil de risque.
| Service | Gestion du cluster | Couverture Defender | Cas d’usage typique |
|---|---|---|---|
| Azure Container Apps | Totalement gérée, serverless | Posture + analyse d’images depuis juillet 2026 | Microservices, APIs événementielles |
| Azure Container Instances | Totalement gérée, à la demande | Posture + analyse d’images depuis juillet 2026 | Tâches batch, jobs ponctuels |
| Azure Kubernetes Service | Plan de contrôle géré, nœuds visibles | Posture, exécution, admission complète | Charges complexes, multi-équipes |
Pour un cluster AKS complet, la configuration de départ diffère sensiblement, notamment sur la gestion des certificats et des identités. Si vous gérez aussi un cluster AKS en parallèle, notre tutoriel sur le déploiement d’un cluster AKS couvre cette base en amont de l’activation de Defender for Cloud. Pour la gestion des secrets injectés dans vos conteneurs, qu’ils tournent sur Container Apps ou sur AKS, référez-vous aussi à notre guide sur Azure Key Vault, qui évite de stocker des identifiants en clair dans les variables d’environnement de vos applications.
Azure face à AWS et Google Cloud : approches comparées
Si votre organisation compare plusieurs fournisseurs avant de choisir où héberger un nouveau service conteneurisé, la logique de facturation de la sécurité diffère sensiblement d’un cloud à l’autre. AWS Security Hub a basculé vers un modèle tarifaire simplifié qui consolide les tarifs entre plusieurs services auparavant facturés séparément, dont Amazon Inspector, GuardDuty et Security Hub CSPM, selon la documentation tarifaire publiée par AWS. Le plan Essentials facture les contrôles de sécurité de façon dégressive : 0,0010 dollar par contrôle pour les 100 000 premiers par compte et par région, puis 0,0008 dollar jusqu’à 400 000, et 0,0005 dollar au-delà. L’ingestion des résultats reste gratuite jusqu’à 10 000 événements par mois.
Cette approche par volume de contrôles contraste avec le modèle Azure, facturé principalement par ressource facturable et par vCore consommé. Ni l’un ni l’autre n’est strictement moins cher dans l’absolu, le résultat dépend du nombre de ressources déployées et de la fréquence des analyses. Une équipe qui fait tourner beaucoup de petites fonctions serverless avec peu de trafic paiera généralement moins cher sur un modèle AWS orienté volume de contrôles. Une équipe avec peu de ressources mais très actives en déploiement continu peut trouver le modèle Azure plus prévisible, puisqu’il ne dépend pas du nombre de vérifications effectuées.
Pour les organisations qui opèrent déjà sur les trois clouds, Defender for Cloud peut connecter des comptes AWS et des projets Google Cloud grâce à son extension multicloud 2026, décrite à l’étape 12. L’intérêt principal n’est pas de remplacer les outils natifs de chaque fournisseur, mais d’obtenir un tableau de bord unique qui évite à un analyste sécurité de jongler entre trois consoles différentes chaque matin.
Ce qu’il faut retenir avant de passer à l’action
Sécuriser Azure Container Apps en 2026 ne demande plus de choisir entre simplicité serverless et visibilité de sécurité. La bascule de facturation du 1er juillet a simplement rendu payant ce qui était auparavant un angle mort pour la plupart des plateformes serverless du marché. Suivre les 13 étapes de ce tutoriel dans l’ordre, sans sauter l’activation explicite de l’étape 4 ni la configuration du registre de l’étape 5, évite la quasi-totalité des pièges listés plus haut.
Le résultat concret après 90 minutes de configuration : un score de sécurisation mesurable, une analyse de vulnérabilités qui tourne à chaque déploiement, et un contrôle d’admission capable de bloquer une mauvaise configuration avant qu’elle n’atteigne la production. C’est un socle suffisant pour documenter une démarche de sécurité sérieuse face à un client, un partenaire bancaire ou un régulateur européen.
Foire aux questions
Faut-il activer Defender for Cloud sur chaque abonnement séparément ?
Oui. L’activation se fait au niveau de l’abonnement, pas au niveau d’une ressource individuelle. Une organisation avec plusieurs abonnements doit répéter l’étape 3 pour chacun, ou automatiser cette activation via une politique Azure appliquée au niveau du groupe de gestion.
Azure Container Apps est-il moins sécurisé qu’AKS par défaut ?
Non, mais il expose moins de leviers de configuration manuelle. Cela réduit la surface d’erreur humaine tout en limitant les options de durcissement personnalisé, un compromis à évaluer selon la sensibilité du workload.
Le contrôle d’admission Kubernetes fonctionne-t-il directement sur Container Apps ?
Le contrôle d’admission tel que décrit à l’étape 7 cible avant tout les clusters Kubernetes gérés comme AKS. Sur Container Apps, la protection équivalente passe par les recommandations de posture et les politiques Azure Policy appliquées au niveau de la ressource ARM.
Combien coûte réellement la protection serverless sur un petit environnement ?
Pour une poignée d’applications Container Apps avec un trafic modéré, la facture mensuelle additionnelle reste généralement de l’ordre de quelques dizaines de dollars. Le coût dépend surtout du nombre de ressources facturables actives, pas du volume de requêtes HTTP.
Peut-on tester cette configuration sans impacter la production ?
Oui, en suivant ce tutoriel dans un groupe de ressources isolé comme recommandé en prérequis. Les plans Defender s’appliquent à l’abonnement entier, mais vous pouvez limiter vos tests de déploiement et de contrôle d’admission à des ressources clairement séparées avant de généraliser.
Que se passe-t-il si je désactive Defender for Containers après l’avoir testé ?
La facturation s’arrête dès la désactivation, mais vous perdez aussi l’historique d’analyse de vulnérabilités et le contrôle d’admission associé. Les recommandations déjà traitées restent visibles un temps dans l’historique, avant de disparaître du tableau de bord actif.
Defender for Cloud couvre-t-il aussi les registres de conteneurs tiers hors d’Azure ?
Oui, à condition de configurer manuellement les identifiants d’accès comme montré à l’étape 5. Docker Hub et d’autres registres compatibles OCI peuvent être connectés, mais l’intégration automatique native reste réservée à Azure Container Registry.
Faut-il connecter AWS et GCP même si l’essentiel du parc tourne sur Azure ?
Cela dépend de votre empreinte réelle. Si quelques workloads tournent sur EKS ou GKE en parallèle, la connexion multicloud décrite à l’étape 12 évite de maintenir deux outils de sécurité distincts avec deux tableaux de bord séparés.
