Meilleures pratiques pour la sécurité des pods dans Azure Kubernetes Service (AKS)

Lorsque vous développez et exécutez des applications dans Azure Kubernetes Service (ACS), la sécurité de vos pods est primordiale. Vos applications doivent être conçues selon le principe du moindre privilège. La sécurité des données privées est la priorité des clients. Vous ne tenez pas à ce que les informations d’identification telles que les chaînes de connexion aux bases de données, les clés, les secrets ou les certificats, soient exposées au monde extérieur, avec le risque qu’un pirate puisse les exploiter à des fins malveillantes. Ne les ajoutez pas à votre code et évitez de les incorporer dans vos images de conteneur. Vos informations risqueraient d’être exposées et cela limiterait votre capacité à changer ces informations d’identification, puisque les images de conteneur devront être reconstruites.

Cet article décrit les bonnes pratiques de sécurisation des pods dans AKS. Vous allez apprendre à effectuer les actions suivantes :

Vous pouvez également consulter les bonnes pratiques pour la sécurité des clusters et la gestion des images conteneur.

Sécuriser l’accès du pod aux ressources

Meilleures pratiques : pour changer d’utilisateur ou de groupe et limiter l’accès aux services et processus de nœud sous-jacents, définissez les paramètres du contexte de sécurité des pods. Affectez le nombre minimal de privilèges requis.

Pour que vos applications s’exécutent correctement, les pods doivent s’exécuter en tant qu’utilisateur ou groupe défini, et non en tant que racine. Le securityContext pour un pod ou un conteneur vous permet de définir des paramètres tels que runAsUser ou fsGroup pour assumer les autorisations appropriées. Affectez uniquement les autorisations requises pour l’utilisateur ou le groupe et n’utilisez pas le contexte de sécurité pour assumer des autorisations supplémentaires. Le runAsUser, élévation des privilèges, et d’autres paramètres de fonctionnalités Linux sont uniquement disponibles sur les pods et nœuds Linux.

Lorsque vous vous connectez en tant qu’utilisateur non root, les conteneurs ne peuvent pas établir de liaison avec les ports privilégiés inférieurs à 1024. Dans ce scénario, Kubernetes Services peut être utilisé pour masquer le fait qu’une application s’exécute sur un port particulier.

Un contexte de sécurité de pod peut également permettre de définir des fonctionnalités ou autorisations supplémentaires pour accéder à des processus et services. Vous pouvez utiliser les définitions de contexte de sécurité courantes ci-dessous :

• allowPrivilegeEscalation définit si le pod peut assumer les privilèges racine. Concevez vos applications afin que ce paramètre soit toujours défini sur false.
• Les fonctionnalités Linux permettent au pod d’accéder aux processus de nœud sous-jacents. Soyez vigilant lorsque vous affectez ces fonctionnalités. Affectez le nombre minimal de privilèges nécessaire. Pour plus d’informations, consultez Fonctionnalités de Linux.
• SELinux Labels est un module de sécurité du noyau Linux qui vous permet de définir des stratégies d’accès pour l’accès aux services, aux processus et au système de fichiers. Là encore, affectez le nombre minimal de privilèges nécessaire. Pour plus d’informations, consultez Options de SELinux dans Kubernetes

L’exemple de manifeste YAML suivant définit les paramètres du contexte de sécurité pour indiquer :

• qu’un pod est exécuté en tant qu’utilisateur portant l’ID 1000 et faisant partie du groupe avec l’ID 2000 ;
• qu’il n’est pas possible d’élever les privilèges pour utiliser root ;
• que les fonctionnalités Linux peuvent accéder aux interfaces réseau et à l’horloge (matérielle) en temps réel de l’hôte.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    fsGroup: 2000
  containers:
    - name: security-context-demo
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      securityContext:
        runAsUser: 1000
        allowPrivilegeEscalation: false
        capabilities:
          add: ["NET_ADMIN", "SYS_TIME"]

Consultez votre opérateur de cluster pour déterminer les paramètres de contexte de sécurité dont vous avez besoin. Essayez de concevoir vos applications de manière à réduire les autorisations et accès supplémentaires dont le pod a besoin. Il existe d’autres fonctionnalités de sécurité qui permettent de limiter l’accès en utilisant les paramètres AppArmor et seccomp (environnement informatique sécurisé) qui peuvent être implémentés par les opérateurs du cluster. Pour plus d’informations, consultez Sécuriser l’accès du conteneur aux ressources.

Limiter l’exposition des informations d’identification

Meilleures pratiques -ne définissez pas d’informations d’identification dans le code de votre application. Utilisez des identités managées pour les ressources Azure pour permettre à votre pod de demander l’accès à d’autres ressources. Vous devez également utiliser un coffre-fort numérique, tel qu’Azure Key Vault, pour stocker et récupérer des clés numériques et informations d’identification. Les identités managées sont conçues pour être utilisées avec des images conteneurs et des pods Linux uniquement.

Pour limiter le risque d’exposition d’informations d’identification dans le code de votre application, évitez d’utiliser des informations d’identification fixes ou partagées. Vous ne devez inclure aucune information d’identification ou clé directement dans votre code. Si ces informations d’identification sont exposées, l’application doit être mise à jour et redéployée. Une meilleure approche consiste à attribuer aux pods leur propre identité ainsi qu’un moyen de s’authentifier d’eux-mêmes, ou de récupérer automatiquement les informations d’identification à partir d’un coffre numérique.

Utiliser un Microsoft Entra Workload ID

Une identité de charge de travail est une identité utilisée par une application s’exécutant sur un pod qui peut s’authentifier elle-même auprès d’autres services Azure qui la prennent en charge, comme Stockage ou SQL. Elle s’intègre aux fonctionnalités natives de Kubernetes pour se fédérer avec des fournisseurs d’identité externes. Dans ce modèle de sécurité, le cluster AKS agit comme un émetteur de jetons, et Microsoft Entra ID utilise OpenID Connect pour découvrir des clés de signature publique et vérifier l’authenticité du jeton de compte de service avant de l’échanger pour un jeton Microsoft Entra. Votre charge de travail peut échanger un jeton de compte de service projeté sur son volume pour un jeton Microsoft Entra en utilisant la bibliothèque cliente Azure Identity avec le SDK Azure ou la bibliothèque d’authentification Microsoft (MSAL).

Pour plus d’informations sur les identités de charge de travail, consultez Configurer un cluster AKS pour utiliser des identités de charge de travail Microsoft Entra Workload ID avec vos applications

Utiliser Azure Key Vault avec le pilote Secrets Store CSI

L’utilisation d’une Microsoft Entra Workload ID vous permet de vous authentifier auprès des services Azure qui le prennent en charge. Si vos propres services ou applications n’ont pas d’identités managées pour les ressources Azure, vous pouvez toujours utiliser des informations d’identification ou des clés pour vous authentifier. Vous pouvez utiliser un coffre numérique pour stocker le contenu de ces secrets.

Lorsque les applications ont besoin d’informations d’identification, elles communiquent avec le coffre numérique, récupèrent le dernier contenu des secrets, puis se connectent au service nécessaire. Azure Key Vault peut être utilisé comme coffre numérique. Le schéma suivant illustre de façon simplifiée le workflow utilisé pour récupérer des informations d’identification à partir d’Azure Key Vault à l’aide d’identités de pod managées :

Key Vault vous permet de stocker et faire tourner régulièrement les secrets, tels que les informations d’identification, les clés de compte de stockage ou les certificats. Vous pouvez intégrer Azure Key Vault à un cluster AKS à l’aide du fournisseur Azure Key Vault pour le pilote Secrets Store CSI. Le pilote Secrets Store CSI permet au cluster AKS de récupérer en mode natif le contenu des secrets à partir de Key Vault, et fournit celui-ci uniquement au pod demandeur. Collaborez avec votre opérateur de cluster pour déployer le pilote Secrets Store CSI sur les nœuds Worker AKS. Vous pouvez utiliser une Microsoft Entra Workload ID pour demander l’accès à Key Vault et récupérer le contenu des secrets par le biais du pilote Secrets Store CSI.

Étapes suivantes

Cet article était dédié à la sécurisation de vos pods. Pour implémenter quelques-unes de ces pratiques, consultez les articles suivants :

• Utiliser Microsoft Entra Workload ID pour les ressources Azure avec AKS
• Intégrer Azure Key Vault à AKS