Implémenter des contrôles de sécurité pour Azure Container Apps
Azure Container Apps fournit une plateforme managée pour l’exécution de microservices en conteneur, d’API et de charges de travail pilotées par les événements. Contrairement à Container Instances, qui exécutent des charges de travail individuelles en isolation, les environnements Container Apps regroupent plusieurs services et partagent l’infrastructure. Ce modèle partagé nécessite une configuration délibérée pour empêcher les services avec différents niveaux de confiance d’interférer entre eux et de s’assurer que les services internes ne sont pas involontairement exposés à Internet.
Comprendre l’environnement Container Apps comme une limite d’isolation
Chaque application conteneur s’exécute dans un environnement Container Apps. L’environnement définit le sous-réseau du réseau virtuel, l’espace de travail Log Analytics partagé et la configuration Dapr que toutes les applications de l’environnement partagent. Les applications dans le même environnement peuvent communiquer sur un espace d’adressage interne privé. Les applications dans différents environnements sont isolées par défaut.
Cette architecture a une implication directe en matière de sécurité : les applications avec différents niveaux de confiance ne doivent pas partager un environnement. Une plateforme de commerce électronique qui exécute à la fois des API publiques et des services principaux internes doit utiliser des environnements distincts , l’environnement principal configuré pour l’accès au réseau virtuel uniquement, l’environnement frontal pour l’entrée externe. Le mélange de services avec différentes exigences d’exposition dans un environnement unique signifie qu’une règle d’entrée mal configurée sur une application peut exposer d’autres services dans le même environnement.
Affecter des identités managées à Container Apps
Container Apps prend en charge les identités managées affectées par le système et celles affectées par l’utilisateur. Utilisez des identités managées pour tirer des images depuis Azure Container Registry, récupérer des secrets depuis Azure Key Vault, appeler les points de terminaison d’Azure OpenAI et d’Azure AI Foundry, et interagir avec tout autre service Azure prenant en charge l’authentification Microsoft Entra.
Pour affecter une identité affectée par le système à une application conteneur :
az containerapp identity assign \
--name <app-name> \
--resource-group <rg> \
--system-assigned
Accordez à l’identité les rôles dont il a besoin. Pour extraire une image depuis Azure Container Registry (ACR) :
az role assignment create \
--assignee <managed-identity-principal-id> \
--role AcrPull \
--scope /subscriptions/<subscription-id>/resourceGroups/<rg>/providers/Microsoft.ContainerRegistry/registries/<registry-name>
Les identités affectées par l’utilisateur sont utiles lorsque plusieurs applications conteneurisées partagent les mêmes autorisations. Créez l’identité une fois, affectez-la aux rôles requis et attachez-la à chaque application qui en a besoin. Cela est plus efficace que la création d’identités affectées par le système distinctes qui ont chacun besoin des mêmes attributions de rôles.
Contrôler l’accès d’entrée
Ingress détermine comment une application conteneurisée reçoit le trafic réseau. Deux modes d’entrée sont disponibles :
- Entrée externe : l’application est accessible à partir de l’Internet public. Il reçoit un nom de domaine complet public et peut être fronté par Azure Front Door ou Application Gateway.
- Entrée interne : l’application est accessible uniquement à partir de l’environnement Container Apps ou d’autres ressources du même réseau virtuel. Aucune adresse IP publique n’est affectée.
Définissez les API backend, les processeurs de files d’attente et les services de données avec une entrée interne. Seuls les services qui doivent réellement être accessibles à partir de l’extérieur de votre réseau doivent utiliser l’entrée externe. L’environnement Contoso Retail avait tous les services configurés comme externes, exposant ainsi des services internes à l’Internet public sans justification métier — l’ingress interne élimine cette exposition par une seule modification de configuration.
Vous pouvez restreindre davantage l’entrée externe à l’aide des restrictions de sécurité IP. Configurez une liste d’autorisation d’adresses IP source de confiance ou de plages CIDR :
az containerapp ingress access-restriction set \
--name <app-name> \
--resource-group <rg> \
--rule-name allow-corporate \
--ip-address 203.0.113.0/24 \
--action Allow
Pour les applications qui servent les utilisateurs authentifiés, utilisez l’intergiciel d’authentification intégré (souvent appelé EasyAuth) pour exiger Microsoft Entra ID connexion avant qu’une demande atteigne votre code de conteneur. Configurez-le dans le portail Azure sous Authentication sur votre application conteneur ou avec l’interface CLI. L’intergiciel intercepte les requêtes non authentifiées et redirige les utilisateurs vers la page de connexion Microsoft Entra ID. Aucune modification du code d’application n’est requise.
Gérer les secrets avec des références à Key Vault
Container Apps fournit deux mécanismes de gestion des secrets.
Les secrets au niveau de l’environnement sont stockés dans la plateforme Container Apps et injectés en tant que variables d’environnement ou montages de volumes au moment de l’exécution. Ils conviennent aux valeurs de configuration qui changent rarement et ne nécessitent pas de rotation centralisée ou d’audit.
Références Key Vault pointent vers un secret dans Azure Key Vault à l’aide d’un URI et récupèrent la valeur au moment de l’exécution à l’aide de l’identité managée de l’application. La valeur secrète n’est jamais stockée dans la configuration container Apps : la plateforme l’extrait chaque fois qu’elle est nécessaire. Il s’agit de l’approche recommandée pour les informations d’identification, les chaînes de connexion et toute valeur qui doit être auditée ou pivotée de manière centralisée.
Pour faire référence à un secret Key Vault :
az containerapp secret set \
--name <app-name> \
--resource-group <rg> \
--secrets "db-connection=keyvaultref:<key-vault-secret-uri>,identityref:<managed-identity-resource-id>"
Lorsque vous faites pivoter la valeur secrète dans Key Vault, l’application conteneur récupère la valeur mise à jour lors du prochain redémarrage du conteneur. Vous ne mettez pas à jour la configuration de l’application conteneur pour prendre en compte le nouveau secret : l’URI de Key Vault reste la même ; seule la valeur vers laquelle elle pointe change.
Sécuriser la communication de service à service avec Dapr
Dapr (Distributed Application Runtime) est un projet de la Cloud Native Computing Foundation (CNCF) qui fournit des fonctionnalités de niveau applicatif grâce à une architecture en side-car. Dans Azure Container Apps, l’activation de Dapr ajoute un conteneur sidecar aux côtés de votre conteneur d’application. Le sidecar gère les appels de service à service, la messagerie pub/sub, la gestion d’état et les liaisons externes — votre application communique avec le sidecar via localhost plutôt que directement avec d’autres services ou infrastructures.
Le comportement de sécurité le plus important fourni par Dapr est le protocole TLS mutuel (mTLS). Les sidecars Dapr négocient et imposent automatiquement le protocole mTLS pour toutes les communications entre services au sein de l’environnement Container Apps. Le trafic entre deux applications compatibles Dapr est chiffré en transit sans aucune configuration requise dans le code de l’application. Vous ne gérez pas les certificats ni n’implémentez TLS dans vos services : Dapr le gère.
Lorsque vous évaluez un environnement Container Apps qui utilise Dapr, vérifiez ces configurations de sécurité :
- Portée des composants : les composants Dapr — tels que les magasins d’état, les brokers pub/sub et les magasins de secrets — peuvent être limités à des applications spécifiques. Sans restriction de périmètre, toute application activée pour Dapr dans l’environnement peut utiliser n’importe quel composant. Utilisez une portée au niveau de l’application pour restreindre chaque composant aux seules applications qui en ont légitimement besoin.
- Configuration du magasin de secrets : configurez le composant de magasin de secrets de Dapr pour utiliser Azure Key Vault, en s’appuyant sur l’identité managée de l’application. Cela élimine les informations d’identification codées en dur dans la configuration des composants Dapr.
- Exposition du tableau de bord Dapr : le tableau de bord Dapr offre une observabilité dans l’exécution des composants Dapr et des services actifs. Vérifiez qu’elle n’est pas exposée avec une entrée externe . Elle ne doit être accessible qu’au sein de l’environnement ou via une connexion réseau privée.
Tip
Pour obtenir une vue d’ensemble complète de l’intégration de Dapr dans Container Apps, notamment la configuration des composants et l’activation de Dapr sur une application existante, consultez Intégration deDapr à Azure Container Apps.