Partager via

Centre pour la Sécurité Internet (CIS) point de référence Kubernetes

En tant que service sécurisé, Azure Kubernetes Service (AKS) est conforme aux normes SOC, ISO, PCI DSS et HIPAA. Cet article couvre le renforcement de la sécurité appliqué à AKS en fonction du point de référence Kubernetes CIS. Pour plus d’informations sur la sécurité AKS, consultez Concepts de sécurité pour les applications et les clusters dans AKS (Azure Kubernetes Service). Pour plus d’informations sur le point de référence CIS, consultez Points de référence CIS (Center for Internet Security).

Point de référence Kubernetes CIS

Voici les résultats des recommandations CIS Kubernetes Benchmark v1.12.0 sur AKS. Les résultats s’appliquent à AKS 1.32.x via AKS 1.34.x. Pour connaître les chronologies de prise en charge, consultez les versions de Kubernetes prises en charge.

Remarque

Outre le benchmark CIS Kubernetes, il existe également un benchmark CIS AKS disponible.

Niveaux de sécurité

Les points de référence CIS fournissent deux niveaux de paramètres de sécurité :

  • L1, ou niveau 1, recommande des exigences de sécurité de base essentielles qui peuvent être configurées sur n’importe quel système et qui doivent entraîner peu ou pas d’interruption de service ni de réduction de fonctionnalités.
  • L2, ou niveau 2, recommande des paramètres de sécurité pour les environnements nécessitant une plus grande sécurité pouvant entraîner une réduction de fonctionnalités.

Statut de l’évaluation

Un état d’évaluation est inclus pour chaque recommandation. L’état de l’évaluation indique si la recommandation donnée peut être automatisée ou nécessite des étapes manuelles à implémenter. Les deux états sont tout aussi importants et sont déterminés et pris en charge comme suit :

  • Automatisée : représente des recommandations pour lesquelles l’évaluation d’un contrôle technique peut être entièrement automatisée et validée en état de réussite/échec. Les recommandations incluent les informations nécessaires pour implémenter l’automatisation.
  • Manuel : représente des recommandations pour lesquelles l’évaluation d’un contrôle technique ne peut pas être entièrement automatisée et nécessite toutes ou certaines étapes manuelles pour vérifier que l’état configuré est défini comme prévu. L’état attendu peut varier en fonction de l’environnement.

Les recommandations automatisées affectent le score du point de référence si elles ne sont pas appliquées, ce qui n’est pas le cas des recommandations manuelles.

État de l'attestation

Les recommandations peuvent avoir l’un des statuts d’attestation suivants :

  • Pass : La recommandation a été appliquée.
  • Échec : la recommandation n’a pas été appliquée.
  • N/A : la recommandation concerne les exigences d’autorisation du fichier manifeste qui ne sont pas pertinentes pour AKS. Par défaut, les clusters Kubernetes utilisent un modèle de manifeste pour déployer les pods du plan de contrôle, qui reposent sur les fichiers de la machine virtuelle du nœud. Le point de référence Kubernetes CIS recommande que ces fichiers disposent de certaines exigences d’autorisation. Les clusters AKS utilisent un chart Helm pour déployer des pods du plan de contrôle et ne dépendent pas de fichiers présents sur la machine virtuelle du nœud.
  • Dépend de l’environnement: la recommandation est appliquée dans l’environnement spécifique de l’utilisateur et n’est pas contrôlée par AKS. Les recommandations automatisées affectent le score du point de référence, que la recommandation s’applique ou non à l’environnement spécifique de l’utilisateur.
  • Contrôle équivalent : la recommandation a été mise en œuvre de manière différente et équivalente.

Détails du point de référence

ID CIS Description de la recommandation Statut de l’évaluation Niveau État Motif
1 Composants du plan de contrôle
1.1 Fichiers de configuration du nœud de plan de contrôle
1.1.1 Veiller à ce que les autorisations du fichier de spécification du pod de serveur d’API soient définies sur 600 ou soient plus restrictives Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.2 Vérifiez que la propriété du fichier de spécification du pod du serveur d’API est définie sur root: root Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.3 Veiller à ce que les autorisations du fichier de spécification du pod de gestionnaire de contrôleurs soient définies sur 600 ou soient plus restrictives Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.4 Vérifiez que la propriété du fichier de spécification de pod du gestionnaire de contrôleur est définie sur root: root Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.5 Veiller à ce que les autorisations du fichier de spécification du pod de planificateur soient définies sur 600 ou soient plus restrictives Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.6 Vérifiez que la propriété du fichier de spécification de pod du planificateur est définie sur root: root Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.7 Veiller à ce que les autorisations du fichier de spécification du pod etcd soient définies sur 600 ou soient plus restrictives Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.8 Vérifiez que la propriété du fichier de spécification de pod etcd est définie sur root: root Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.9 Veiller à ce que les autorisations du fichier d’interface réseau du conteneur soient définies sur 600 ou soient plus restrictives Manuel L1 N/A N/A, car AKS est une solution managée
1.1.10 Vérifiez que la propriété du fichier d’interface réseau de conteneur est définie sur root: root Manuel L1 N/A N/A, car AKS est une solution managée
1.1.11 Veiller à ce que les autorisations du répertoire de données etcd soient définies sur 700 ou plus restrictives Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.12 Vérifier que la propriété du répertoire de données etcd a la valeur etcd:etcd Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.13 Veiller à ce que les autorisations du fichier admin.conf soient définies sur 600 ou soient plus restrictives Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.14 Vérifiez que la propriété du fichier admin.conf est définie sur root: root Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.15 Veiller à ce que les autorisations du fichier scheduler.conf soient définies sur 600 ou soient plus restrictives Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.16 Vérifiez que la propriété du fichier scheduler.conf est définie sur root: root Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.17 Veiller à ce que les autorisations du fichier controller-manager.conf soient définies sur 600 ou soient plus restrictives Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.18 Vérifiez que la propriété du fichier controller-manager.conf est définie sur root: root Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.19 Vérifiez que le répertoire PKI Kubernetes et la propriété de fichier sont définis sur root: root Automatisé L1 N/A N/A, car AKS est une solution managée
1.1.20 Veiller à ce que les autorisations du fichier de certificat PKI Kubernetes soient définies sur 600 ou soient plus restrictives Manuel L1 N/A N/A, car AKS est une solution managée
1.1.21 Veiller à ce que les autorisations du fichier de clés PKI Kubernetes soient définies sur 600 Manuel L1 N/A N/A, car AKS est une solution managée
1.2 Serveur d’API
1.2.1 Veiller à ce que l’argument --anonymous-auth soit défini sur false Manuel L1 Réussite
1.2.2 Vérifiez que le --token-auth-file paramètre n’est pas défini Automatisé L1 Échec Pivoté automatiquement par AKS, le paramètre est actuellement défini
1.2.3 Vérifiez que --DenyServiceExternalIPs n'est pas configuré. Manuel L1 Échec Les clients peuvent utiliser Azure Policy pour Kubernetes pour refuser les services avec une adresse IP externe.
1.2.4 Veiller à ce que les arguments --kubelet-client-certificate et --kubelet-client-key soient définis comme il convient Automatisé L1 Réussite
1.2.5 Veiller à ce que l’argument --kubelet-certificate-authority soit défini comme il convient Automatisé L1 Échec Le certificat de service Kubelet utilise un certificat auto-signé
1.2.6 Vérifiez que l’argument --authorization-mode n’est pas défini sur AlwaysAllow Automatisé L1 Réussite
1.2.7 Veiller à ce que l’argument --authorization-mode inclue Node Automatisé L1 Réussite
1.2.8 Veiller à ce que l’argument --authorization-mode inclue RBAC Automatisé L1 Réussite
1.2.9 Veiller à ce que le plug-in de contrôle d’admission EventRateLimit soit défini Manuel L1 Échec Impact sur l’exploitation
1.2.10 Vérifiez que le plug-in de contrôle d’admission AlwaysAdmit n’est pas défini Automatisé L1 Réussite
1.2.11 Veiller à ce que le plug-in de contrôle d’admission AlwaysPullImages soit défini Manuel L1 Échec Impact sur l’exploitation
1.2.12 Veiller à ce que le plug-in de contrôle d’admission ServiceAccount soit défini Automatisé L2 Réussite
1.2.13 Veiller à ce que le plug-in de contrôle d’admission NamespaceLifecycle soit défini Automatisé L2 Réussite
1.2.14 Veiller à ce que le plug-in de contrôle d’admission NodeRestriction soit défini Automatisé L2 Réussite
1.2.15 Veiller à ce que l’argument --profiling soit défini sur false Automatisé L1 Réussite
1.2.16 Veiller à ce que l’argument --audit-log-path soit défini Automatisé L1 Réussite
1.2.17 Veiller à ce que l’argument --audit-log-maxage soit défini sur 30 ou comme il convient Automatisé L1 Contrôle équivalent AKS stocke le journal d’audit pendant 14 jours, Deployment.yaml a la valeur 0.
1.2.18 Veiller à ce que l’argument --audit-log-maxbackup soit défini sur 10 ou comme il convient Automatisé L1 Contrôle équivalent AKS stocke le journal d’audit pendant 14 jours, Deployment.yaml a la valeur 0.
1.2.19 Veiller à ce que l’argument --audit-log-maxsize soit défini sur 100 ou comme il convient Automatisé L1 Réussite
1.2.20 Veiller à ce que l’argument --request-timeout soit défini comme il convient Manuel L1 Réussite Le paramètre n’est pas défini, ce qui définit la valeur par défaut = 60s (conforme)
1.2.21 Veiller à ce que l’argument --service-account-lookup soit défini sur true Automatisé L1 Réussite Le paramètre n’est pas défini, ce qui définit la valeur par défaut comme true (qui est conforme)
1.2.22 Veiller à ce que l’argument --service-account-key-file soit défini comme il convient Automatisé L1 Réussite
1.2.23 Veiller à ce que les arguments --etcd-certfile et --etcd-keyfile soient définis comme il convient Automatisé L1 Réussite
1.2.24 Veiller à ce que les arguments --tls-cert-file et --tls-private-key-file soient définis comme il convient Automatisé L1 Réussite
1.2.25 Veiller à ce que l’argument --client-ca-file soit défini comme il convient Automatisé L1 Réussite
1.2.26 Veiller à ce que l’argument --etcd-cafile soit défini comme il convient Automatisé L1 Réussite
1.2.27 Veiller à ce que l’argument --encryption-provider-config soit défini comme il convient Manuel L1 Dépend de l’environnement L’argument est défini lorsque Azure KMS est activé
1.2.28 Veiller à ce que les fournisseurs de chiffrement soient correctement configurés Manuel L1 Dépend de l’environnement L’argument est défini lorsque Azure KMS est activé
1.2.29 Veiller à ce que le serveur d’API utilise uniquement des chiffrements forts Manuel L1 Réussite AKS prend en charge un sous-ensemble de 4 suites de chiffrement fortes parmi les 21 recommandées par le CIS.
1.2.30 Vérifiez que le --service-account-extend-token-expiration paramètre est défini sur false Automatisé L1 Dépend de l’environnement Ce paramètre est défini sur false lorsque OIDC est activé sur le cluster
1.3 Gestionnaire de contrôleurs
1.3.1 Veiller à ce que l’argument --terminated-pod-gc-threshold soit défini comme il convient Manuel L1 Réussite AKS définit la valeur par défaut sur 6000 au lieu de 12500
1.3.2 Veiller à ce que l’argument --profiling soit défini sur false Automatisé L1 Réussite
1.3.3 Veiller à ce que l’argument --use-service-account-credentials soit défini sur true Automatisé L1 Réussite
1.3.4 Veiller à ce que l’argument --service-account-private-key-file soit défini comme il convient Automatisé L1 Réussite
1.3.5 Veiller à ce que l’argument --root-ca-file soit défini comme il convient Automatisé L1 Réussite
1.3.6 Veiller à ce que l’argument RotateKubeletServerCertificate soit défini sur true Automatisé L2 Réussite Le paramètre est défini sur true, voir Rotation des certificats de service Kubelet
1.3.7 Veiller à ce que l’argument --bind-address soit défini sur 127.0.0.1 Automatisé L1 Contrôle équivalent L’adresse IP du pod est utilisée
1.4 Planificateur
1.4.1 Veiller à ce que l’argument --profiling soit défini sur false Automatisé L1 Réussite
1.4.2 Veiller à ce que l’argument --bind-address soit défini sur 127.0.0.1 Automatisé L1 Contrôle équivalent L’adresse IP du pod est utilisée
2 etcd
2.1 Veiller à ce que les arguments --cert-file et --key-file soient définis comme il convient Automatisé L1 Réussite
2,2 Veiller à ce que l’argument --client-cert-auth soit défini sur true Automatisé L1 Réussite
2.3 Vérifiez que l’argument --auto-tls n’est pas défini sur true Automatisé L1 Réussite Le paramètre n’est pas défini, ce qui définit la valeur par défaut comme false (conforme)
2.4 Veiller à ce que les arguments --peer-cert-file et --peer-key-file soient définis comme il convient Automatisé L1 Réussite
2.5 Veiller à ce que l’argument --peer-client-cert-auth soit défini sur true Automatisé L1 Réussite
2.6 Vérifiez que l’argument --peer-auto-tls n’est pas défini sur true Automatisé L1 Réussite Le paramètre n’est pas défini, ce qui définit la valeur par défaut comme false (conforme)
2.7 Vérifier qu’une autorité de certification unique est utilisée pour etcd Manuel L2 Réussite --client-ca-file pour api-server est différent de --trusted-ca-file pour etcd
3 Configuration du plan de contrôle
3.1 Authentification et autorisation
3.1.1 L’authentification par certificat client ne doit pas être utilisée pour les utilisateurs Manuel L1 Réussite Lors du déploiement d’un cluster AKS, les comptes locaux sont activés par défaut. Vous pouvez désactiver les comptes locaux pour désactiver les certificats clients pour l’authentification.
3.1.2 L’authentification par jeton de compte de service ne doit pas être utilisée pour les utilisateurs Manuel L1 Réussite AKS prend en charge l’authentification Microsoft Entra pour les demandes envoyées au plan de contrôle du cluster. L’utilisation des jetons de compte de service est laissée au client (pour appliquer une bonne pratique, si nécessaire)
3.1.3 L’authentification par jeton de démarrage ne doit pas être utilisée pour les utilisateurs Manuel L1 Réussite Les tokens Bootstrap ne peuvent pas être utilisés par les utilisateurs
3.2 Journalisation
3.2.1 Veiller à ce qu’une stratégie d’audit minimale soit créée Manuel L1 Réussite
3.2.2 Veiller à ce que la stratégie d’audit couvre les problèmes de sécurité clés Manuel L2 Réussite
4 Nœuds Workers
4,1 Fichiers de configuration du nœud Worker
4.1.1 Veiller à ce que les autorisations du fichier de service kubelet soient définies sur 600 ou soient plus restrictives Automatisé L1 Réussite
4.1.2 Vérifiez que la propriété du fichier de service kubelet est définie sur root: root Automatisé L1 Réussite
4.1.3 S’il existe un fichier kubeconfig de proxy, veiller à ce que les autorisations soient définies sur 600 ou soient plus restrictives Manuel L1 N/A
4.1.4 Si un fichier kubeconfig proxy existe, vérifiez que la propriété est définie sur root: root Manuel L1 N/A
4.1.5 Veiller à ce que les autorisations du fichier kubelet.conf --kubeconfig soient définies sur 600 ou soient plus restrictives Automatisé L1 Réussite
4.1.6 Vérifiez que la propriété du --kubeconfig fichier kubelet.conf est définie sur root: root Automatisé L1 Réussite
4.1.7 Veiller à ce que les autorisations du fichier des autorités de certification soient définies sur 600 ou soient plus restrictives Manuel L1 Réussite
4.1.8 Vérifiez que la propriété du fichier des autorités de certification client est définie sur root: root Manuel L1 Réussite
4.1.9 Si le fichier de configuration kubelet config.yaml est utilisé, veiller à ce que les autorisations sont définies sur 600 ou soient plus restrictives Automatisé L1 Réussite
4.1.10 Si le fichier de configuration kubelet config.yaml est utilisé, vérifiez que la propriété du fichier est définie sur root: root Automatisé L1 Réussite
4,2 Kubelet
4.2.1 Veiller à ce que l’argument --anonymous-auth soit défini sur false Automatisé L1 Réussite
4.2.2 Vérifiez que l’argument --authorization-mode n’est pas défini sur AlwaysAllow Automatisé L1 Réussite
4.2.3 Veiller à ce que l’argument --client-ca-file soit défini comme il convient Automatisé L1 Réussite
4.2.4 Veiller à ce que l’argument --read-only-port soit défini sur 0 Manuel L1 Réussite
4.2.5 Vérifiez que l’argument --streaming-connection-idle-timeout n’est pas défini sur 0 Manuel L1 Réussite
4.2.6 Veiller à ce que l’argument --make-iptables-util-chains soit défini sur true Automatisé L1 Réussite
4.2.7 Vérifiez que l’argument --hostname-override n’est pas défini Manuel L1 Réussite
4.2.8 Veiller à ce que l’argument --eventRecordQPS soit défini à un niveau qui garantit la capture d’événements appropriée. Manuel L2 Réussite
4.2.9 Veiller à ce que les arguments --tls-cert-file et --tls-private-key-file soient définis comme il convient Manuel L1 Réussite
4.2.10 Vérifiez que l’argument --rotate-certificates n’est pas défini sur false Automatisé L1 Réussite
4.2.11 Vérifiez que l’argument RotateKubeletServerCertificate soit défini sur true Manuel L1 Réussite
4.2.12 Veiller à ce que Kubelet utilise uniquement des chiffrements forts Manuel L1 Réussite
4.2.13 Vérifiez qu’une limite est définie sur les PID de pod Manuel L1 Réussite
4.2.14 Assurez-vous que Kubelet applique le profil seccomp RuntimeDefault Manuel L1 Dépend de l’environnement AKS est défini par défaut sur Unconfined. La configuration de nœud personnalisée peut être utilisée pour activer le RuntimeDefault profil seccomp.
4.3 kube-proxy
4.3.1 Vérifiez que le service de métriques kube-proxy est lié à localhost Automatisé L1 Échec AKS dispose d'un scraping centralisé Prometheus pour kube-proxy et applique une alerte ainsi qu'une correction automatique lorsqu'un problème KubeProxyStale est détecté. La metrics-bind-address valeur est définie à cet effet.
5 Stratégies
5.1 RBAC et comptes de service
5.1.1 Veiller à ce que le rôle d’administrateur de cluster soit utilisé uniquement lorsque cela est nécessaire Automatisé L1 Dépend de l’environnement Utiliser des définitions de stratégie intégrées Azure Policy pour Azure Kubernetes Service
5.1.2 Réduire au maximum l’accès aux secrets Automatisé L1 Dépend de l’environnement
5.1.3 Réduire au minimum l’utilisation de caractères génériques dans les rôles et les ClusterRoles Automatisé L1 Dépend de l’environnement Utiliser des définitions de stratégie intégrées Azure Policy pour Azure Kubernetes Service
5.1.4 Réduire au minimum l’accès pour créer des pods Automatisé L1 Dépend de l’environnement
5.1.5 Vérifiez que les comptes de service par défaut ne sont pas activement utilisés Automatisé L1 Dépend de l’environnement
5.1.6 Veiller à ce que les jetons de compte de service soient montés seulement quand c’est nécessaire Automatisé L1 Dépend de l’environnement
5.1.7 Éviter d’utiliser le système : groupe masters Manuel L1 Dépend de l’environnement
5.1.8 Limiter l’utilisation des autorisations Bind, Impersonate et Escalate dans le cluster Kubernetes Manuel L1 Dépend de l’environnement
5.1.9 Réduire au maximum l’accès à la création de volumes persistants Manuel L1 Dépend de l’environnement
5.1.10 Réduire l’accès à la sous-ressource proxy des nœuds Manuel L1 Dépend de l’environnement
5.1.11 Réduire l’accès à la sous-ressource d’approbation des certificatesigningrequests objets Manuel L1 Dépend de l’environnement
5.1.12 Réduire au maximum l’accès aux objets de configuration de webhook Manuel L1 Dépend de l’environnement
5.1.13 Réduire au maximum l’accès à la création de jetons de compte de service Manuel L1 Dépend de l’environnement
5.2 Normes de sécurité des pods
5.2.1 Vérifier que le cluster dispose au moins d’un mécanisme de contrôle de stratégie actif en place Manuel L1 Dépend de l’environnement Utiliser des définitions de stratégie intégrées Azure Policy pour Azure Kubernetes Service
5.2.2 Réduire au maximum l’admission des conteneurs privilégiés Manuel L1 Dépend de l’environnement Utiliser des définitions de stratégie intégrées Azure Policy pour Azure Kubernetes Service
5.2.3 Réduire au minimum l’admission des conteneurs qui veulent partager l’espace de noms de l’ID du processus hôte Manuel L1 Dépend de l’environnement Utiliser des définitions de stratégie intégrées Azure Policy pour Azure Kubernetes Service
5.2.4 Réduire au maximum l’admission des conteneurs souhaitant partager l’espace de noms IPC hôte Manuel L1 Dépend de l’environnement Utiliser des définitions de stratégie intégrées Azure Policy pour Azure Kubernetes Service
5.2.5 Réduire au maximum l’admission des conteneurs souhaitant partager l’espace de noms de réseau hôte Manuel L1 Dépend de l’environnement Utiliser des définitions de stratégie intégrées Azure Policy pour Azure Kubernetes Service
5.2.6 Réduire au maximum l’admission des conteneurs avec allowPrivilegeEscalation Manuel L1 Dépend de l’environnement Utiliser des définitions de stratégie intégrées Azure Policy pour Azure Kubernetes Service
5.2.7 Réduire au maximum l’admission des conteneurs racine Manuel L2 Dépend de l’environnement
5.2.8 Réduire au maximum l’admission des conteneurs avec la fonctionnalité NET_RAW Manuel L1 Dépend de l’environnement Utiliser des définitions de stratégie intégrées Azure Policy pour Azure Kubernetes Service
5.2.9 Réduire au minimum l’admission des conteneurs avec des fonctionnalités ajoutées Manuel L1 Dépend de l’environnement Utiliser des définitions de stratégie intégrées Azure Policy pour Azure Kubernetes Service
5.2.10 Réduire au minimum l’admission des conteneurs avec des fonctionnalités affectées Manuel L2 Dépend de l’environnement
5.2.11 Réduire au maximum l’admission des conteneurs HostProcess Windows Manuel L1 Dépend de l’environnement
5.2.12 Réduire au minimum l’admission des volumes HostPath Manuel L1 Dépend de l’environnement Utiliser des définitions de stratégie intégrées Azure Policy pour Azure Kubernetes Service
5.2.13 Réduire au maximum l’admission des conteneurs qui utilisent HostPorts Manuel L1 Dépend de l’environnement
5.3 Stratégies réseau et CNI
5.3.1 Veiller à ce que le CNI en cours d’utilisation prenne en charge les politiques réseau Manuel L1 Réussite
5.3.2 Veiller à ce que des stratégies réseau soient définies pour tous les espaces de noms Manuel L2 Dépend de l’environnement
5.4 Gestion des secrets
5.4.1 Préférer l’utilisation de secrets comme fichiers aux secrets en tant que variables d’environnement Manuel L2 Dépend de l’environnement
5.4.2 Envisagez l'utilisation d'un stockage externe pour les secrets Manuel L2 Dépend de l’environnement
5.5 Contrôle d’admission extensible
5.5.1 Configurer la provenance des images à l’aide du contrôleur d’admission ImagePolicyWebhook Manuel L2 Échec Contrôle équivalent implémenté
5.6 Stratégies générales
5.6.1 Créer des limites administratives entre les ressources à l’aide d’espaces de noms Manuel L1 Dépend de l’environnement
5.6.2 Veiller à ce que le profil seccomp soit défini sur docker/par défaut dans vos définitions de pod Manuel L2 Dépend de l’environnement
5.6.3 Appliquer le contexte de sécurité à vos pods et conteneurs Manuel L2 Dépend de l’environnement
5.6.4 L’espace de noms par défaut ne doit pas être utilisé Manuel L2 Dépend de l’environnement

Autres remarques

  • Le système d’exploitation avec durcissement de la sécurité est conçu et géré spécifiquement pour AKS et n’est pas pris en charge en dehors de la plateforme AKS.
  • Pour réduire encore la surface d’attaque, certains pilotes de module de noyau inutiles sont désactivés dans le système d’exploitation.

Étapes suivantes

Pour plus d’informations sur la sécurité AKS, consultez les articles suivants :

  • Last updated on