Concepts de sécurité dans AKS activés par Azure Arc
S’applique à : AKS sur Azure Stack HCI 22H2, AKS sur Windows Server
La sécurité dans AKS activée par Azure Arc implique la sécurisation de l’infrastructure et des applications s’exécutant sur le cluster Kubernetes. AKS activé par Arc prend en charge les options de déploiement hybride pour Azure Kubernetes Service (AKS). Cet article décrit les mesures de renforcement de la sécurité et les fonctionnalités de sécurité intégrées utilisées pour sécuriser l’infrastructure et les applications sur les clusters Kubernetes.
Infrastructure de sécurité
AKS activé par Arc applique différentes mesures de sécurité pour sécuriser son infrastructure. Le diagramme ci-dessous met en évidence les mesures suivantes :
Le tableau suivant décrit les aspects de renforcement de la sécurité d’AKS sur Azure Local présentés dans le diagramme précédent. Pour obtenir des informations conceptuelles sur l’infrastructure d’un déploiement AKS, consultez Clusters et charges de travail.
| Aspect de la sécurité | Description |
|---|---|
| 1 | Étant donné que l’hôte AKS a accès à tous les clusters de charge de travail (cible), ce cluster peut être un point de compromis unique. Toutefois, l’accès à l’hôte AKS est soigneusement contrôlé, car l’objectif du cluster de gestion est limité à l’approvisionnement des clusters de charge de travail et à la collecte de métriques de cluster agrégées. |
| 2 | Pour réduire le coût et la complexité du déploiement, les clusters de charge de travail partagent le serveur Windows sous-jacent. Toutefois, selon les besoins de sécurité, les administrateurs peuvent choisir de déployer un cluster de charge de travail sur un serveur Windows Server dédié. Quand des clusters de charge de travail partagent le serveur Windows Server sous-jacent, chaque cluster est déployé en tant que machine virtuelle. Cela garantit une isolation fortes entre les clusters de charge de travail. |
| 3 | Les charges de travail client sont déployées en tant que conteneurs, et partagent la même machine virtuelle. Les processus des conteneurs sont isolés. Ce type d’isolation est plus faible que l’isolation qu’offrent des machines virtuelles. |
| 4 | Les conteneurs communiquent entre eux via un réseau superposé. Les administrateurs peuvent configurer des stratégies Calico afin de définir des règles d’isolation de réseau entre les conteneurs. La prise en charge de la stratégie Calico sur AKS Arc est uniquement pour les conteneurs Linux et est prise en charge tel quel. |
| 5 | La communication entre les composants Kubernetes intégrés d’AKS sur Azure Local, notamment la communication entre le serveur d’API et l’hôte de conteneur, est chiffrée via des certificats. AKS offre un approvisionnement, un renouvellement et une révocation de certificats intégrés prêtes à l’emploi. |
| 6 | La communication avec le serveur d’API à partir de machines clientes Windows est sécurisée à l’aide des informations d’identification Microsoft Entra pour les utilisateurs. |
| 7 | Pour chaque version, Microsoft fournit les disques durs virtuels pour les machines virtuelles AKS sur Azure Local et applique les correctifs de sécurité appropriés si nécessaire. |
Sécurité des applications
Le tableau suivant décrit les différentes options de sécurité des applications disponibles dans AKS activées par Arc :
Remarque
Vous avez la possibilité d’utiliser les options de renforcement des applications code source ouvert disponibles dans l’écosystème code source ouvert que vous choisissez.
| Option | Description |
|---|---|
| Intégrer la sécurité | L’objectif de sécurisation des builds consiste à empêcher l’introduction de vulnérabilités dans le code d’application ou dans les images conteneur lors de la génération de celles-ci. L’intégration à Azure GitOps de Kubernetes, qui est compatible avec Azure Arc, permet d’analyser et d’observer, ce qui permet aux développeurs de résoudre les problèmes de sécurité. Pour plus d’informations, consultez Déployer des configurations à l’aide de GitOps sur un cluster Kubernetes avec Azure Arc. |
| Sécurité du registre de conteneurs | L’objectif de la sécurité du registre de conteneurs est de veiller à ce que des vulnérabilités ne soient pas introduites lors du chargement d’images conteneur dans le registre, quand l’image est stockée dans le registre et lors du téléchargement d’images à partir du registre. AKS recommande d’utiliser Azure Container Registry. Azure Container Registry est fourni avec l’analyse des vulnérabilités et d’autres fonctionnalités de sécurité. Pour plus d’informations, consultez la Documentation Azure Container Registry. |
| Identités Microsoft Entra pour les charges de travail Windows à l’aide de gMSA pour conteneurs | Les charges de travail de conteneur Windows peuvent hériter de l’identité de l’hôte de conteneur et l’utiliser à des fins d’authentification. Avec les nouvelles améliorations, l’hôte de conteneur n’a pas besoin d’être joint à un domaine. Pour plus d’informations, consultez Intégration de gMSA pour les charges de travail Windows. |
Fonctionnalités de sécurité intégrées
Cette section décrit les fonctionnalités de sécurité intégrées actuellement disponibles dans AKS activées par Azure Arc :
| Objectif de sécurité | Fonctionnalité |
|---|---|
| Protéger l’accès au serveur API. | Prise en charge de l’authentification unique Active Directory pour les clients PowerShell et Windows Admin Center. Cette fonctionnalité n’est actuellement activée que pour les clusters de charge de travail. |
| Assurez-vous que toutes les communications entre les composants Kubernetes intégrés du plan de contrôle sont sécurisées. Cela implique de s’assurer que la communication entre le serveur API et le cluster de charge de travail est également sécurisée. | Solution de certificat intégrée Zero Touch pour approvisionner, renouveler et révoquer les certificats. Pour plus d’informations, consultez Sécuriser la communication avec des certificats. |
| Opérez une rotation des clés de chiffrement du magasin des secrets Kubernetes (etcd) à l’aide du plug-in Serveur gestionnaire de clés (KMS). | Plug-in pour l’intégration et l’orchestration de la rotation des clés avec le fournisseur KMS spécifié. Pour plus d’informations, consultez Chiffrer les secrets etcd. |
| Surveillance des menaces en temps réel pour les conteneurs qui prennent en charge les charges de travail des conteneurs Windows et Linux. | Intégration à Azure Defender pour Kubernetes connectée à Azure Arc, qui est proposée en préversion publique jusqu’à la publication en disponibilité générale de la détection des menaces Kubernetes pour Kubernetes connectée à Azure Arc. Pour plus d’informations, consultez Défendre les clusters Kubernetes avec Azure Arc. |
| Identité Microsoft Entra pour les charges de travail Windows. | Utilisez l’intégration gMSA pour les charges de travail Windows pour configurer l’identité Microsoft Entra. |
| Prise en charge des stratégies Calico pour sécuriser le trafic entre pods | Les conteneurs communiquent entre eux via un réseau superposé. Les administrateurs peuvent configurer des stratégies Calico afin de définir des règles d’isolation de réseau entre les conteneurs. La prise en charge de la stratégie Calico sur AKS Arc est uniquement pour les conteneurs Linux et est prise en charge tel quel. |
Étapes suivantes
Dans cette rubrique, vous avez découvert les concepts de sécurisation d’AKS activés par Azure Arc et sur la sécurisation des applications sur des clusters Kubernetes.