Meilleures pratiques pour la sécurité des pods dans Azure Kubernetes Service (AKS)Best practices for pod security in 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.As you develop and run applications in Azure Kubernetes Service (AKS), the security of your pods is a key consideration. Vos applications doivent être conçues selon le principe du moindre privilège.Your applications should be designed for the principle of least number of privileges required. La sécurité des données privées est la priorité des clients.Keeping private data secure is top of mind for customers. 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.You don't want credentials like database connection strings, keys, or secrets and certificates exposed to the outside world where an attacker could take advantage of those secrets for malicious purposes. Ne les ajoutez pas à votre code et évitez de les incorporer dans vos images de conteneur.Don't add them to your code or embed them in your container images. 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.This approach would create a risk for exposure and limit the ability to rotate those credentials as the container images will need to be rebuilt.

Cet article décrit les bonnes pratiques de sécurisation des pods dans AKS.This best practices article focuses on how to secure pods in AKS. Vous allez apprendre à effectuer les actions suivantes :You learn how to:

  • Utiliser le contexte de sécurité des pods pour limiter l’accès aux processus et services ou l’élévation de privilègesUse pod security context to limit access to processes and services or privilege escalation
  • S’authentifier avec d’autres ressources Azure à l’aide d’identités de pod managéesAuthenticate with other Azure resources using pod managed identities
  • Demander et récupérer des informations d’identification à partir d’un coffre numérique tel qu’Azure Key VaultRequest and retrieve credentials from a digital vault such as Azure Key Vault

Vous pouvez également consulter les bonnes pratiques pour la sécurité des clusters et la gestion des images conteneur.You can also read the best practices for cluster security and for container image management.

Sécuriser l’accès du pod aux ressourcesSecure pod access to resources

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.Best practice guidance - To run as a different user or group and limit access to the underlying node processes and services, define pod security context settings. Affectez le nombre minimal de privilèges requis.Assign the least number of privileges required.

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 .For your applications to run correctly, pods should run as a defined user or group and not as root . 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.The securityContext for a pod or container lets you define settings such as runAsUser or fsGroup to assume the appropriate permissions. 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.Only assign the required user or group permissions, and don't use the security context as a means to assume additional permissions. 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.The runAsUser , privilege escalation, and other Linux capabilities settings are only available on Linux nodes and pods.

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.When you run as a non-root user, containers cannot bind to the privileged ports under 1024. Dans ce scénario, Kubernetes Services peut être utilisé pour masquer le fait qu’une application s’exécute sur un port particulier.In this scenario, Kubernetes Services can be used to disguise the fact that an app is running on a particular port.

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.A pod security context can also define additional capabilities or permissions for accessing processes and services. Vous pouvez utiliser les définitions de contexte de sécurité courantes ci-dessous :The following common security context definitions can be set:

  • allowPrivilegeEscalation définit si le pod peut assumer les privilèges racine .allowPrivilegeEscalation defines if the pod can assume root privileges. Concevez vos applications afin que ce paramètre soit toujours défini sur false .Design your applications so this setting is always set to false .
  • Les fonctionnalités Linux permettent au pod d’accéder aux processus de nœud sous-jacents.Linux capabilities let the pod access underlying node processes. Soyez vigilant lorsque vous affectez ces fonctionnalités.Take care with assigning these capabilities. Affectez le nombre minimal de privilèges nécessaire.Assign the least number of privileges needed. Pour plus d’informations, consultez Fonctionnalités de Linux.For more information, see Linux capabilities.
  • 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.SELinux labels is a Linux kernel security module that lets you define access policies for services, processes, and filesystem access. Là encore, affectez le nombre minimal de privilèges nécessaire.Again, assign the least number of privileges needed. Pour plus d’informations, consultez Options de SELinux dans KubernetesFor more information, see SELinux options in Kubernetes

L’exemple de manifeste YAML suivant définit les paramètres du contexte de sécurité pour indiquer :The following example pod YAML manifest sets security context settings to define:

  • qu’un pod est exécuté en tant qu’utilisateur portant l’ID 1000 et faisant partie du groupe avec l’ID 2000 ;Pod runs as user ID 1000 and part of group ID 2000
  • qu’il n’est pas possible d’élever les privilèges pour utiliser root ;Can't escalate privileges to use 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.Allows Linux capabilities to access network interfaces and the host's real-time (hardware) clock
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.Work with your cluster operator to determine what security context settings you need. Essayez de concevoir vos applications de manière à réduire les autorisations et accès supplémentaires dont le pod a besoin.Try to design your applications to minimize additional permissions and access the pod requires. 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.There are additional security features to limit access using AppArmor and seccomp (secure computing) that can be implemented by cluster operators. Pour plus d’informations, consultez Sécuriser l’accès du conteneur aux ressources.For more information, see Secure container access to resources.

Limiter l’exposition des informations d’identificationLimit credential exposure

Meilleures pratiques -ne définissez pas d’informations d’identification dans le code de votre application.Best practice guidance - Don't define credentials in your application code. Utilisez des identités managées pour les ressources Azure pour permettre à votre pod de demander l’accès à d’autres ressources.Use managed identities for Azure resources to let your pod request access to other resources. 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.A digital vault, such as Azure Key Vault, should also be used to store and retrieve digital keys and credentials. Les identités managées sont conçues pour être utilisées avec des images conteneurs et des pods Linux uniquement.Pod managed identities is intended for use with Linux pods and container images only.

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.To limit the risk of credentials being exposed in your application code, avoid the use of fixed or shared credentials. Vous ne devez inclure aucune information d’identification ou clé directement dans votre code.Credentials or keys shouldn't be included directly in your code. Si ces informations d’identification sont exposées, l’application doit être mise à jour et redéployée.If these credentials are exposed, the application needs to be updated and redeployed. 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.A better approach is to give pods their own identity and way to authenticate themselves, or automatically retrieve credentials from a digital vault.

Utiliser des projets Azure Container Compute UpstreamUse Azure Container Compute Upstream projects

Important

Les projets open source AKS associés ne sont pas pris en charge par le support technique Azure.Associated AKS open source projects are not supported by Azure technical support. Ils sont fournis pour permettre aux utilisateurs une installation automatique dans les clusters, et une collecte de commentaires à partir de notre communauté.They are provided for users to self-install into clusters and gather feedback from our community.

Les projets open source AKS associés suivants vous permettent d’authentifier automatiquement les pods, ou de demander des informations d’identification et des clés auprès d’un coffre numérique.The following associated AKS open source projects let you automatically authenticate pods or request credentials and keys from a digital vault. Ces projets sont gérés par l’équipe Azure Container Compute Upstream et font partie d’une plus large liste de projets disponibles.These projects are maintained by the Azure Container Compute Upstream team and are part of a broader list of projects available for use.

Utiliser des identités de pod managéesUse pod managed identities

Une identité managée pour les ressources Azure permet à un pod de s’authentifier lui-même auprès de services Azure qui le prennent en charge, comme le service Stockage ou SQL.A managed identity for Azure resources lets a pod authenticate itself against Azure services that support it, such as Storage or SQL. Le pod se voit attribuer une identité Azure qui lui permet de s’authentifier auprès d’Azure Active Directory et de recevoir un jeton numérique.The pod is assigned an Azure Identity that lets them authenticate to Azure Active Directory and receive a digital token. Ce jeton numérique peut être présenté à d’autres services Azure qui vérifient si le pod est autorisé à accéder au service et à effectuer les actions requises.This digital token can be presented to other Azure services that check if the pod is authorized to access the service and perform the required actions. Cette approche signifie par exemple qu’aucun secret n’est nécessaire pour les chaînes de connexion à la base de données.This approach means that no secrets are required for database connection strings, for example. Le worflow simplifié du système d’identités de pod managées est représenté dans le schéma suivant :The simplified workflow for pod managed identity is shown in the following diagram:

Workflow simplifié du système d’identités de pod managées dans Azure

Avec une identité managée, il n’est pas nécessaire d’inclure des informations d’identification dans le code de votre application pour accéder à un service, tel que Stockage Azure.With a managed identity, your application code doesn't need to include credentials to access a service, such as Azure Storage. Puisque chaque pod s’authentifie avec sa propre identité, vous pouvez contrôler et réviser les accès.As each pod authenticates with its own identity, so you can audit and review access. Si votre application se connecte auprès d’autres services Azure, utilisez des identités managées pour limiter la réutilisation d’informations d’identification et le risque d’exposition.If your application connects with other Azure services, use managed identities to limit credential reuse and risk of exposure.

Pour plus d’informations sur les identités de pod, consultez Configurer un cluster AKS pour utiliser des identités de pod managées et avec vos applicationsFor more information about pod identities, see Configure an AKS cluster to use pod managed identities and with your applications

Utiliser Azure Key Vault avec le pilote Secrets Store CSIUse Azure Key Vault with Secrets Store CSI Driver

L’utilisation du projet d’identités de pod vous permet de vous authentifier auprès des services Azure qui le prennent en charge.Using the pod identity project enables authentication against supporting Azure services. 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.For your own services or applications without managed identities for Azure resources, you can still authenticate using credentials or keys. Vous pouvez utiliser un coffre numérique pour stocker le contenu de ces secrets.A digital vault can be used to store these secret contents.

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.When applications need a credential, they communicate with the digital vault, retrieve the latest secret contents, and then connect to the required service. Azure Key Vault peut être utilisé comme coffre numérique.Azure Key Vault can be this digital vault. 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 :The simplified workflow for retrieving a credential from Azure Key Vault using pod managed identities is shown in the following diagram:

Workflow simplifié pour récupérer des informations d’identification dans Key Vault à l’aide d’une identité de pod managée

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.With Key Vault, you store and regularly rotate secrets such as credentials, storage account keys, or certificates. Vous pouvez intégrer Azure Key Vault à un cluster AKS à l’aide du fournisseur Azure Key Vault pour le pilote Secrets Store CSI.You can integrate Azure Key Vault with an AKS cluster using the Azure Key Vault provider for the Secrets Store CSI Driver. 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.The Secrets Store CSI driver enables the AKS cluster to natively retrieve secret contents from Key Vault and securely provide them only to the requesting pod. Collaborez avec votre opérateur de cluster pour déployer le pilote Secrets Store CSI sur les nœuds Worker AKS.Work with your cluster operator to deploy the Secrets Store CSI Driver onto AKS worker nodes. Vous pouvez utiliser une identité managée par un pod pour demander l’accès à Key Vault et récupérer le contenu des secrets par le biais du pilote Secrets Store CSI.You can use a pod managed identity to request access to Key Vault and retrieve the secret contents needed through the Secrets Store CSI Driver.

Azure Key Vault et le pilote Secrets Store CSI peuvent être utilisés pour les nœuds et les pods Linux qui nécessitent une version de Kubernetes supérieure ou égale à 1.16.Azure Key Vault with Secrets Store CSI Driver can be used for Linux nodes and pods which require a Kubernetes version of 1.16 or greater. Pour les nœuds et les pods Windows, vous avez besoin de Kubernetes version 1.18 ou supérieure.For Windows nodes and pods a Kubernetes version of 1.18 or greater is required.

Étapes suivantesNext steps

Cet article était dédié à la sécurisation de vos pods.This article focused on how to secure your pods. Pour implémenter quelques-unes de ces pratiques, consultez les articles suivants :To implement some of these areas, see the following articles: