Meilleures pratiques relatives aux mises à jour et à la sécurité du cluster dans Azure Kubernetes Service (AKS)Best practices for cluster security and upgrades in Azure Kubernetes Service (AKS)

Quand vous gérez des clusters dans Azure Kubernetes Service (AKS), la sécurité de vos charges de travail et données est un point important.As you manage clusters in Azure Kubernetes Service (AKS), the security of your workloads and data is a key consideration. Et ce tout particulièrement lorsque vous exécutez des clusters avec plusieurs locataires à l’aide de l’isolation logique ; l’accès aux ressources et charges de travail doit être sécurisé.Especially when you run multi-tenant clusters using logical isolation, you need to secure access to resources and workloads. Pour réduire le risque d’attaque, vous devez également vous assurer que vous appliquez les dernières mises à jour de sécurité de système d’exploitation de nœud et Kubernetes.To minimize the risk of attack, you also need to make sure you apply the latest Kubernetes and node OS security updates.

Cet article est dédié à la sécurisation de votre cluster AKS.This article focuses on how to secure your AKS cluster. Vous allez apprendre à effectuer les actions suivantes :You learn how to:

  • Utiliser Azure Active Directory et le contrôle d’accès en fonction du rôle Kubernetes (RBAC Kubernetes) pour sécuriser l’accès au serveur d’APIUse Azure Active Directory and Kubernetes role-based access control (Kubernetes RBAC) to secure API server access
  • Sécuriser l’accès du conteneur aux ressources de nœudSecure container access to node resources
  • Mettre à niveau un cluster AKS avec la dernière version de KubernetesUpgrade an AKS cluster to the latest Kubernetes version
  • Maintenir les nœuds à jour et appliquer automatiquement des correctifs de sécuritéKeep nodes up to date and automatically apply security patches

Vous pouvez également consulter les meilleures pratiques relatives à la gestion des images conteneur et à la sécurité du pod.You can also read the best practices for container image management and for pod security.

Vous pouvez également utiliser Intégration des services Azure Kubernetes avec Security Center pour détecter les menaces et afficher des recommandations pour sécuriser vos clusters AKS.You can also use Azure Kubernetes Services integration with Security Center to help detect threats and view recommendations for securing your AKS clusters.

Sécuriser l’accès aux nœuds de cluster et au serveur d’APISecure access to the API server and cluster nodes

Meilleures pratiques - La sécurisation de l’accès au serveur d’API Kubernetes est l’une des choses les plus importantes à faire pour protéger votre cluster.Best practice guidance - Securing access to the Kubernetes API-Server is one of the most important things you can do to secure your cluster. Intégrez le contrôle d’accès en fonction du rôle Kubernetes (RBAC Kubernetes) à Azure Active Directory pour contrôler l’accès au serveur d’API.Integrate Kubernetes role-based access control (Kubernetes RBAC) with Azure Active Directory to control access to the API server. Ces contrôles vous permettent de sécuriser AKS de la même façon que vous sécurisez l’accès à vos abonnements Azure.These controls let you secure AKS the same way that you secure access to your Azure subscriptions.

Le serveur d’API Kubernetes propose un point de connexion unique pour que les requêtes exécutent des actions dans un cluster.The Kubernetes API server provides a single connection point for requests to perform actions within a cluster. Pour sécuriser et auditer l’accès au serveur d’API, limitez l’accès et proposez les autorisations d’accès avec le moins de privilèges requises.To secure and audit access to the API server, limit access and provide the least privileged access permissions required. Cette approche n’est pas unique à Kubernetes, mais est particulièrement importante lorsque le cluster AKS est isolé de façon logique pour une utilisation avec plusieurs locataires.This approach isn't unique to Kubernetes, but is especially important when the AKS cluster is logically isolated for multi-tenant use.

Azure Active Directory (AD) fournit une solution de gestion des identités d’entreprise qui s’intègre aux clusters AKS.Azure Active Directory (AD) provides an enterprise-ready identity management solution that integrates with AKS clusters. Comme Kubernetes ne fournit pas de solution de gestion des identités, il peut être difficile de proposer une méthode granulaire pour restreindre l’accès au serveur d’API.As Kubernetes doesn't provide an identity management solution, it can otherwise be hard to provide a granular way to restrict access to the API server. Avec les clusters intégrés Azure AD dans AKS, vous utilisez vos comptes groupe et utilisateur existants pour authentifier les utilisateurs sur le serveur d’API.With Azure AD-integrated clusters in AKS, you use your existing user and group accounts to authenticate users to the API server.

Intégration Azure Active Directory aux clusters AKS

Utilisez l’intégration Azure AD Kubernetes et le contrôle d’accès en fonction du rôle pour sécuriser le serveur d’API et fournir le nombre minimal d’autorisations requises pour un ensemble donné de ressources, comme un espace de noms unique.Use Kubernetes RBAC and Azure AD-integration to secure the API server and provide the least number of permissions required to a scoped set of resources, such as a single namespace. Différents utilisateurs ou groupes dans Azure AD peuvent se voir accorder différents rôles Kubernetes.Different users or groups in Azure AD can be granted different Kubernetes roles. Ces autorisations granulaires vous permettent de restreindre l’accès au serveur d’API et fournissent une piste d’audit claire des actions effectuées.These granular permissions let you restrict access to the API server, and provide a clear audit trail of actions performed.

La meilleure pratique recommandée consiste à utiliser des groupes pour fournir un accès aux fichiers et dossiers plutôt que des identités individuelles ; utilisez l’appartenance au groupe Azure AD pour lier les utilisateurs aux rôles de contrôle d’accès en fonction des rôles Kubernetes plutôt que des utilisateurs individuels.The recommended best practice is to use groups to provide access to files and folders versus individual identities, use Azure AD group membership to bind users to Kubernetes roles rather than individual users. Étant donné que l’appartenance au groupe d’un utilisateur change, ses autorisations d’accès sur le cluster AKS changent en conséquence.As a user's group membership changes, their access permissions on the AKS cluster would change accordingly. Si vous liez l’utilisateur directement à un rôle, sa fonction peut changer.If you bind the user directly to a role, their job function may change. Les appartenances au groupe Azure AD peuvent être mises à jour, mais les autorisations sur le cluster AKS ne le refléteraient pas.The Azure AD group memberships would update, but permissions on the AKS cluster would not reflect that. Dans ce scénario, l’utilisateur finit par se voir accorder davantage d’autorisations que nécessaire.In this scenario, the user ends up being granted more permissions than a user requires.

Pour plus d’informations sur l’intégration Azure AD, RBAC Kubernetes et RBAC Azure, consultez les Meilleures pratiques relatives à l’authentification et à l’autorisation dans AKS.For more information about Azure AD integration, Kubernetes RBAC, and Azure RBAC, see Best practices for authentication and authorization in AKS.

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

Meilleures pratiques - Limitez l’accès aux actions que les conteneurs peuvent effectuer.Best practice guidance - Limit access to actions that containers can perform. Fournissez le plus petit nombre d’autorisations et évitez d’utiliser l’escalade de privilèges/racine.Provide the least number of permissions, and avoid the use of root / privileged escalation.

De la même façon que vous devez accorder aux utilisateurs ou groupes le nombre minimal de privilèges requis, les conteneurs doivent également être limités aux actions et processus nécessaires uniquement.In the same way that you should grant users or groups the least number of privileges required, containers should also be limited to only the actions and processes that they need. Pour réduire le risque d’attaque, ne configurez pas les applications et les conteneurs qui nécessitent des privilèges escaladés ou un accès racine.To minimize the risk of attack, don't configure applications and containers that require escalated privileges or root access. Par exemple, définissez allowPrivilegeEscalation: false dans le manifeste de pod.For example, set allowPrivilegeEscalation: false in the pod manifest. Ces contextes de sécurité de pod sont intégrés à Kubernetes et vous permettent de définir des autorisations supplémentaires telles que l’identité du groupe ou de l’utilisateur à exécuter, ou les fonctionnalités Linux à exposer.These pod security contexts are built in to Kubernetes and let you define additional permissions such as the user or group to run as, or what Linux capabilities to expose. Pour plus de meilleures pratiques, consultez Sécuriser l’accès du pod aux ressources.For more best practices, see Secure pod access to resources.

Pour un contrôle plus précis des actions de conteneur, vous pouvez également utiliser les fonctionnalités de sécurité Linux intégrées telles que AppArmor et seccomp.For more granular control of container actions, you can also use built-in Linux security features such as AppArmor and seccomp. Ces fonctionnalités sont définies au niveau du nœud, puis implémentées via un manifeste de pod.These features are defined at the node level, and then implemented through a pod manifest. Les fonctionnalités de sécurité Linux intégrées sont disponibles sur les nœuds et les pods Linux uniquement.Built-in Linux security features are only available on Linux nodes and pods.

Nota

Les environnements Kubernetes, dans AKS ou ailleurs, ne sont pas totalement sûrs pour une utilisation multi-locataire hostile.Kubernetes environments, in AKS or elsewhere, aren't completely safe for hostile multi-tenant usage. Des fonctionnalités de sécurité supplémentaires, comme AppArmor, seccomp ou des stratégies de sécurité Pod, ainsi qu’un contrôle d’accès en fonction du rôle Kubernetes (RBAC Kubernetes) plus détaillé pour les nœuds rendent les attaques plus difficiles.Additional security features such as AppArmor, seccomp, Pod Security Policies, or more fine-grained Kubernetes role-based access control (Kubernetes RBAC) for nodes make exploits more difficult. Mais lors de l’exécution de charges de travail multi-locataires hostiles, seul un hyperviseur garantira véritablement la sécurité.However, for true security when running hostile multi-tenant workloads, a hypervisor is the only level of security that you should trust. Le domaine de sécurité de Kubernetes devient le cluster, et non un nœud individuel.The security domain for Kubernetes becomes the entire cluster, not an individual node. Pour ces types de charges de travail multi-locataires hostiles, vous devez utiliser des clusters physiquement isolés.For these types of hostile multi-tenant workloads, you should use physically isolated clusters.

AppArmorApp Armor

Pour limiter les actions réalisables par les conteneurs, vous pouvez utiliser le module de sécurité du noyau Linux AppArmor.To limit the actions that containers can perform, you can use the AppArmor Linux kernel security module. AppArmor est disponible dans le cadre du système d’exploitation de nœud AKS sous-jacent et est activé par défaut.AppArmor is available as part of the underlying AKS node OS, and is enabled by default. Vous créez des profils AppArmor qui limitent les actions telles que la lecture, l’écriture ou l’exécution ou des fonctions système telles que le montage de systèmes de fichiers.You create AppArmor profiles that restrict actions such as read, write, or execute, or system functions such as mounting filesystems. Les profils AppArmor par défaut limitent l’accès à divers emplacements /proc et /sys, et fournissent un moyen pour isoler de façon logique les conteneurs à partir du nœud sous-jacent.Default AppArmor profiles restrict access to various /proc and /sys locations, and provide a means to logically isolate containers from the underlying node. AppArmor fonctionne pour n’importe quelle application qui s’exécute sur Linux, pas seulement les pods Kubernetes.AppArmor works for any application that runs on Linux, not just Kubernetes pods.

Profils AppArmor en cours d’utilisation dans un cluster AKS pour limiter les actions de conteneur

Pour voir AppArmor en action, l’exemple suivant crée un profil qui empêche l’écriture de fichiers.To see AppArmor in action, the following example creates a profile that prevents writing to files. Établissez une connexion SSH vers un nœud AKS, puis créez un fichier nommé deny-write.profile et collez le contenu suivant :SSH to an AKS node, then create a file named deny-write.profile and paste the following content:

#include <tunables/global>
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>
  
  file,
  # Deny all file writes.
  deny /** w,
}

Les profils AppArmor sont ajoutés à l’aide de la commande apparmor_parser.AppArmor profiles are added using the apparmor_parser command. Ajoutez le profil à AppArmor et spécifiez le nom du profil créé dans l’étape précédente :Add the profile to AppArmor and specify the name of the profile created in the previous step:

sudo apparmor_parser deny-write.profile

Aucune sortie n’est renvoyée si le profil est correctement analysé et appliqué à AppArmor.There's no output returned if the profile is correctly parsed and applied to AppArmor. Vous êtes redirigé vers l’invite de commandes.You're returned to the command prompt.

Depuis votre ordinateur local, créez maintenant un manifeste de pod nommé aks-apparmor.yaml et collez le contenu suivant.From your local machine, now create a pod manifest named aks-apparmor.yaml and paste the following content. Ce manifeste définit une annotation pour container.apparmor.security.beta.kubernetes et fait référence au profil deny-write créé dans les étapes précédentes :This manifest defines an annotation for container.apparmor.security.beta.kubernetes add references the deny-write profile created in the previous steps:

apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
  annotations:
    container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
spec:
  containers:
  - name: hello
    image: busybox
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

Déployez l’exemple de pod à l’aide de la commande kubectl apply :Deploy the sample pod using the kubectl apply command:

kubectl apply -f aks-apparmor.yaml

Une fois le pod déployé, utilisez la commande kubectl exec pour écrire dans un fichier.With the pod deployed, use the kubectl exec command to write to a file. La commande ne peut pas être exécutée, comme indiqué dans l’exemple de sortie suivant :The command can't be executed, as shown in the following example output:

$ kubectl exec hello-apparmor touch /tmp/test

touch: /tmp/test: Permission denied
command terminated with exit code 1

Pour plus d’informations sur AppArmor, consultez les Profils AppArmor dans Kubernetes.For more information about AppArmor, see AppArmor profiles in Kubernetes.

Sécuriser le calculSecure computing

Tandis qu’AppArmor fonctionne pour toutes les applications Linux, seccomp (sec ure comp uting) agit au niveau du processus.While AppArmor works for any Linux application, seccomp (sec ure comp uting) works at the process level. Seccomp est également un module de sécurité du noyau Linux, pris en charge de façon native par le runtime Docker utilisé par les nœuds AKS.Seccomp is also a Linux kernel security module, and is natively supported by the Docker runtime used by AKS nodes. Avec seccomp, les appels de processus que les conteneurs peuvent effectuer sont limités.With seccomp, the process calls that containers can perform are limited. Vous créez des filtres qui définissent les actions à autoriser ou refuser, puis utilisez des annotations au sein d’un manifeste YAML de pod à associer au filtre seccomp.You create filters that define what actions to allow or deny, and then use annotations within a pod YAML manifest to associate with the seccomp filter. Cela coïncide avec la meilleure pratique consistant à accorder au conteneur uniquement les autorisations minimales devant être exécutées.This aligns to the best practice of only granting the container the minimal permissions that are needed to run, and no more.

Pour voir seccomp en action, créez un filtre qui empêche la modification des autorisations sur un fichier.To see seccomp in action, create a filter that prevents changing permissions on a file. Établissez une connexion SSH vers un nœud AKS, puis créez un filtre seccomp nommé /var/lib/kubelet/seccomp/prevent-chmod et collez le contenu suivant :SSH to an AKS node, then create a seccomp filter named /var/lib/kubelet/seccomp/prevent-chmod and paste the following content:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "name": "chmod",
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

Depuis votre ordinateur local, créez maintenant un manifeste de pod nommé aks-seccomp.yaml et collez le contenu suivant.From your local machine, now create a pod manifest named aks-seccomp.yaml and paste the following content. Ce manifeste définit une annotation pour seccomp.security.alpha.kubernetes.io et fait référence au filtre prevent-chmod créé dans les étapes précédentes :This manifest defines an annotation for seccomp.security.alpha.kubernetes.io and references the prevent-chmod filter created in the previous step:

apiVersion: v1
kind: Pod
metadata:
  name: chmod-prevented
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: localhost/prevent-chmod
spec:
  containers:
  - name: chmod
    image: busybox
    command:
      - "chmod"
    args:
     - "777"
     - /etc/hostname
  restartPolicy: Never

Déployez l’exemple de pod à l’aide de la commande kubectl apply :Deploy the sample pod using the kubectl apply command:

kubectl apply -f ./aks-seccomp.yaml

Affichez l’état des pods à l’aide de la commande kubectl get pods.View the status of the pods using the kubectl get pods command. Le pod signale une erreur.The pod reports an error. La commande chmod ne peut pas être exécutée en raison du filtre seccomp, comme affiché dans l’exemple de sortie suivant :The chmod command is prevented from running by the seccomp filter, as shown in the following example output:

$ kubectl get pods

NAME                      READY     STATUS    RESTARTS   AGE
chmod-prevented           0/1       Error     0          7s

Pour plus d’informations sur les filtres disponibles, consultez les Profils de sécurité seccomp pour Docker.For more information about available filters, see Seccomp security profiles for Docker.

Effectuer des mises à jour régulières vers la dernière version de KubernetesRegularly update to the latest version of Kubernetes

Bonnes pratiques - Pour rester informé des nouvelles fonctionnalités et correctifs de bogues, effectuez des mises à jour régulières vers la version Kubernetes dans votre cluster AKS.Best practice guidance - To stay current on new features and bug fixes, regularly upgrade the Kubernetes version in your AKS cluster.

Kubernetes sort de nouvelles fonctionnalités à un rythme plus effréné que les plateformes d’infrastructure plus traditionnelles.Kubernetes releases new features at a quicker pace than more traditional infrastructure platforms. Les mises à jour Kubernetes incluent de nouvelles fonctionnalités et des correctifs de sécurité ou de bogues.Kubernetes updates include new features, and bug or security fixes. En général, les nouvelles fonctionnalités passent d’un état alpha, puis bêta avant d’atteindre un état stable et d’être disponibles et recommandées pour une utilisation en production.New features typically move through an alpha and then beta status before they become stable and are generally available and recommended for production use. Ce cycle devrait vous permettre de mettre à jour Kubernetes sans rencontrer de changements cassants ou ajuster vos déploiements et modèles.This release cycle should allow you to update Kubernetes without regularly encountering breaking changes or adjusting your deployments and templates.

AKS prend en charge trois versions mineures de Kubernetes.AKS supports three minor versions of Kubernetes. Cela signifie que, quand une nouvelle version de correctif mineure est introduite, la version mineure et les publications des correctifs les plus anciennes prises en charge sont mises hors service.This means that when a new minor patch version is introduced, the oldest minor version and patch releases supported are retired. Les mises à jour mineures de Kubernetes se produisent sur une base périodique.Minor updates to Kubernetes happen on a periodic basis. Vérifiez que vous disposez d’un processus de gouvernance pour consulter et effectuer les mises à niveau nécessaires, afin de ne pas vous retrouver sans support.Make sure that you have a governance process to check and upgrade as needed so you don't fall out of support. Pour plus d’informations, consultez la section Versions de Kubernetes prises en charge dans AKS.For more information, see Supported Kubernetes versions AKS.

Pour consulter les versions disponibles pour votre cluster, utilisez la commande az aks get-upgrades comme indiqué dans l’exemple suivant :To check the versions that are available for your cluster, use the az aks get-upgrades command as shown in the following example:

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster

Vous pouvez ensuite mettre à niveau votre cluster AKS à l’aide de la commande az aks upgrade.You can then upgrade your AKS cluster using the az aks upgrade command. Le processus de mise à niveau ferme et vide en toute sécurité un nœud à la fois, planifie les pods sur les nœuds restants, puis déploie un nouveau nœud exécutant les dernières versions de Kubernetes et du système d’exploitation.The upgrade process safely cordons and drains one node at a time, schedules pods on remaining nodes, and then deploys a new node running the latest OS and Kubernetes versions.

Il est vivement recommandé de tester les nouvelles versions mineures dans un environnement de développement-test, de sorte que vous puissiez vérifier que votre charge de travail continue de fonctionner normalement avec la nouvelle version de Kubernetes.It is highly recommended to test new minor versions in a dev test environment so you can validate your workload continues healthy operation with the new Kubernetes version. Il est possible que certaines API soient déconseillées par Kubernetes, comme dans la version 1.16, sur laquelle vos charges de travail pouvaient se baser.Kubernetes may deprecate APIs, such as in version 1.16, which could be relied on by your workloads. Lors de la mise en production de nouvelles versions, envisagez d’utiliser plusieurs pools de nœuds sur des versions distinctes et de mettre à niveau les pools individuels un par un pour déployer progressivement la mise à jour sur l’ensemble du cluster.When bringing new versions into production, consider using multiple node pools on separate versions and upgrade individual pools one at a time to progressively roll the update across a cluster. Si vous exécutez plusieurs clusters, mettez-les à niveau l’un après l’autre de manière à surveiller progressivement l’impact ou les modifications.If running multiple clusters, upgrade one cluster at a time to progressively monitor for impact or changes.

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION

Pour plus d’informations sur les mises à niveau dans AKS, consultez Versions de Kubernetes prises en charge dans Azure Kubernetes Service (AKS) et Mise à jour d’un cluster Azure Kubernetes Service (AKS).For more information about upgrades in AKS, see Supported Kubernetes versions in AKS and Upgrade an AKS cluster.

Traiter les mises à jour et les redémarrages de nœuds Linux avec kuredProcess Linux node updates and reboots using kured

Bonnes pratiques – AKS télécharge et installe automatiquement les correctifs de sécurité sur chacun des nœuds Linux, mais ne les redémarre pas automatiquement si nécessaire.Best practice guidance - AKS automatically downloads and installs security fixes on each Linux nodes, but does not automatically reboot if necessary. Utilisez kured pour surveiller les redémarrages en attente, puis fermez et videz le nœud en toute sécurité pour qu’il puisse redémarrer, appliquer les mises à jour et être aussi sûr que possible à l’égard du système d’exploitation.Use kured to watch for pending reboots, then safely cordon and drain the node to allow the node to reboot, apply the updates and be as secure as possible with respect to the OS. Pour les nœuds Windows Server, effectuez régulièrement une opération de mise à niveau AKS pour isoler et drainer de façon sécurisée les pods et déployer les nœuds mis à jour.For Windows Server nodes, regularly perform an AKS upgrade operation to safely cordon and drain pods and deploy updated nodes.

Chaque soir, les nœuds Linux d’AKS obtiennent les correctifs de sécurité disponibles via le canal de mise à jour de leur distribution.Each evening, Linux nodes in AKS get security patches available through their distro update channel. Ce comportement est automatiquement configuré à mesure que les nœuds sont déployés dans un cluster AKS.This behavior is configured automatically as the nodes are deployed in an AKS cluster. Pour minimiser les perturbations et l’impact potentiel sur les charges de travail en cours d’exécution, les nœuds ne sont pas automatiquement redémarrés si un correctif de sécurité ou mise à jour du noyau l’exige.To minimize disruption and potential impact to running workloads, nodes are not automatically rebooted if a security patch or kernel update requires it.

Le projet kured (KUbernetes REboot Daemon) open source de Weaveworks surveille les redémarrages de nœud en attente.The open-source kured (KUbernetes REboot Daemon) project by Weaveworks watches for pending node reboots. Quand un nœud Linux applique des mises à jour qui nécessitent un redémarrage, le nœud est isolé et drainé de manière sécurisée pour déplacer et planifier les pods sur d’autres nœuds du cluster.When a Linux node applies updates that require a reboot, the node is safely cordoned and drained to move and schedule the pods on other nodes in the cluster. Après le redémarrage du nœud, ce dernier est de nouveau ajouté au cluster, et Kubernetes reprend la planification des pods sur celui-ci.Once the node is rebooted, it is added back into the cluster and Kubernetes resumes scheduling pods on it. Pour limiter les perturbations, un seul nœud à la fois est autorisé à être redémarré par kured.To minimize disruption, only one node at a time is permitted to be rebooted by kured.

Le processus de redémarrage du nœud AKS à l’aide de kured

Si vous souhaitez contrôler plus précisément le moment où les redémarrages se produisent, kured peut s’intégrer à Prometheus afin d’éviter les redémarrages si d’autres événements de maintenance ou problèmes de cluster sont en cours.If you want finer grain control over when reboots happen, kured can integrate with Prometheus to prevent reboots if there are other maintenance events or cluster issues in progress. Cette intégration réduit les complications supplémentaires en redémarrant les nœuds pendant que vous résolvez de façon active les autres problèmes.This integration minimizes additional complications by rebooting nodes while you are actively troubleshooting other issues.

Pour plus d’informations sur le traitement des redémarrages de nœud, consultez la sectionAppliquer des mises à jour de sécurité et du noyau à des nœuds dans AKS.For more information about how to handle node reboots, see Apply security and kernel updates to nodes in AKS.

Étapes suivantesNext steps

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