Bonnes pratiques relatives à l’isolation de clusters dans Azure Kubernetes Service (AKS)
Quand vous gérez des clusters dans Azure Kubernetes Service (AKS), il est souvent nécessaire d’isoler les équipes et les charges de travail. AKS vous offre une certaine flexibilité dans la manière d’exécuter les clusters multilocataires et d’isoler les ressources. Pour maximiser votre investissement dans Kubernetes, il est important de comprendre les fonctionnalités de multilocation et d’isolation d’AKS.
Cet article traite des bonnes pratiques d’isolation pour les opérateurs de clusters. Dans cet article, vous apprendrez comment :
- Préparez des clusters multilocataires et la séparation des ressources.
- Utilisez l’isolement logique ou physique dans vos clusters AKS.
Concevoir des clusters pour la multilocation
Kubernetes vous permet d’isoler logiquement les équipes et les charges de travail dans le même cluster. L’objectif est de fournir le moins de privilèges possible sur les seules ressources dont chaque équipe a besoin. Un espace de noms dans Kubernetes crée une limite d’isolation logique. Voici d’autres fonctionnalités et considérations liées à l’isolation et à la multilocation dans Kubernetes :
Planification
La planification utilise des fonctionnalités de base telles que les quotas de ressources et les budgets de perturbation de pod. Pour plus d’informations sur ces fonctionnalités, consultez Bonnes pratiques relatives aux fonctionnalités de base du planificateur dans AKS.
Les fonctionnalités plus avancées du planificateur sont les suivantes :
- Teintes et tolérances.
- Sélecteurs de nœud.
- Affinité de nœud et de pod ou anti-affinité.
Pour plus d’informations sur ces fonctionnalités, consultez Bonnes pratiques relatives aux fonctionnalités avancées du planificateur dans AKS.
Mise en réseau
Le réseau utilise des stratégies réseau pour contrôler le flux du trafic à destination et en provenance des pods.
Authentification et autorisation
L’authentification et l’autorisation utilisent :
- Contrôle d’accès en fonction du rôle (RBAC).
- Intégration Microsoft Entra.
- Identités de pod.
- Secrets dans Azure Key Vault.
Pour plus d’informations sur ces fonctionnalités, consultez Bonnes pratiques relatives à l’authentification et à l’autorisation dans AKS.
Containers
Les conteneurs sont les suivants :
- Le module complémentaire Azure Policy pour AKS pour appliquer la sécurité des pods.
- Admission de sécurité des pods.
- L’analyse des images et du runtime pour identifier les vulnérabilités.
- Utilisation d’App Armor ou de Seccomp (Secure Computing) pour restreindre l’accès du conteneur au nœud sous-jacent.
Clusters isolés logiquement
Conseils sur les bonnes pratiques
La séparation des équipes et des projets à l’aide de l’isolation logique. Réduire le nombre de clusters AKS physiques que vous déployez pour isoler les équipes ou les applications.
Grâce à l’isolation logique, vous pouvez utiliser un même cluster AKS pour plusieurs charges de travail, équipes ou environnements. Les espaces de noms Kubernetes forment la limite d’isolation logique pour les charges de travail et les ressources.
La séparation logique des clusters fournit généralement une densité de pod supérieure à celle des clusters physiquement isolés, avec une capacité de calcul en attente moins importante dans le cluster. En combinant cette approche à l’outil Kubernetes de mise à l’échelle automatique de cluster (« autoscaler »), vous pouvez effectuer un scale-up ou un scale-down des nœuds pour répondre aux demandes. Cette meilleure pratique vous permet de minimiser les coûts en exécutant uniquement le nombre de nœuds nécessaires.
Les environnements Kubernetes ne sont pas sûrs pour une utilisation multilocataire hostile. Dans un environnement multilocataire, plusieurs locataires travaillent sur une infrastructure partagée. Si tous les locataires ne peuvent pas être approuvés, vous aurez besoin d’une planification supplémentaire pour empêcher les locataires d’avoir un impact sur la sécurité et le service des autres.
Des fonctionnalités de sécurité supplémentaires, comme le contrôle d’accès RBAC Kubernetes pour les nœuds, bloquent efficacement les codes malveillants exploitant une faille de sécurité. Pour une véritable sécurité lors de l’exécution de charges de travail multi-locataires hostiles, vous ne devez faire confiance qu’à un hyperviseur. Le domaine de sécurité de Kubernetes devient le cluster, et non un nœud individuel.
Pour ces types de charges de travail multi-locataires hostiles, vous devez utiliser des clusters physiquement isolés.
Clusters isolés physiquement
Conseils sur les bonnes pratiques
Réduisez l’utilisation de l’isolation physique pour chaque équipe ou déploiement d’application et utilisez plutôt l’isolation logique.
Une approche courante en matière d’isolation de cluster consiste à utiliser des clusters AKS séparés physiquement. Dans ce modèle d’isolation, les équipes ou charges de travail se voient affecter leur propre cluster AKS. Bien que l’isolation physique peut sembler être la façon la plus simple d’isoler des charges de travail ou des équipes, elle ajoute une surcharge de gestion et financière. Avec des clusters isolés physiquement, vous devez gérer plusieurs clusters, et fournir un accès et affecter des autorisations à chacun d’eux. Chaque nœud individuel est sont également facturé.
Les clusters isolés physiquement offrent généralement une faible densité de pods. Comme chaque équipe ou charge de travail a son propre cluster AKS, le cluster est fréquemment surprovisionné avec des ressources de calcul. Souvent, peu de pods sont planifiés sur ces nœuds. Toute capacité de nœud inutilisée ne peut pas être exploitée par d’autres équipes pour des applications ou des services en cours de développement. Cet excédent de ressources engendre des frais supplémentaires pour les clusters isolés physiquement.
Étapes suivantes
Dans cet article, nous avons traité de l’isolation des clusters. Pour plus d’informations sur les opérations liées aux clusters dans AKS, consultez ces articles relatifs aux meilleures pratiques :