Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article vous montre comment utiliser des mesures de sécurité de déploiement pour appliquer les meilleures pratiques sur un cluster Azure Kubernetes Service (AKS).
Vue d’ensemble
Remarque
Les mesures de sécurité de déploiement sont activées par défaut dans AKS Automatic.
Tout au long du cycle de vie du développement, il est courant que des bogues, des problèmes et d’autres problèmes surviennent si le déploiement initial de vos ressources Kubernetes inclut des configurations incorrectes. Pour faciliter le fardeau du développement Kubernetes, Azure Kubernetes Service (AKS) offre de mesures de sécurité de déploiement. Les mesures de sécurité de déploiement appliquent les meilleures pratiques Kubernetes dans votre cluster AKS via des contrôles Azure Policy.
Les mesures de sécurité de déploiement offrent deux niveaux de configuration :
-
Warn: affiche les messages d’avertissement dans le terminal de code pour vous avertir de toutes les configurations de cluster non conformes, mais permet toujours d’effectuer la requête. -
Enforce: applique des configurations de conformité en refusant et en mutant les déploiements s’ils ne suivent pas les meilleures pratiques.
Après avoir configuré les mesures de sécurité de déploiement pour « Avertir » ou « Appliquer », les mesures de sécurité de déploiement évaluent de manière programmatique la conformité de vos ressources Kubernetes au moment de la création ou de la mise à jour. Les mesures de sécurité de déploiement affichent également des informations de conformité agrégées sur vos charges de travail à un niveau de ressource par le biais du tableau de bord de conformité d’Azure Policy dans le portail Azure ou dans votre interface CLI ou votre terminal. L’exécution d’une charge de travail non conforme indique que votre cluster ne suit pas les meilleures pratiques et que les charges de travail sur votre cluster risquent de rencontrer des problèmes causés par la configuration de votre cluster.
Prérequis
Remarque
Les administrateurs de cluster n’ont pas besoin d’autorisations Azure Policy pour activer ou désactiver les mesures de sécurité de déploiement. Toutefois, il est nécessaire d’installer le module complémentaire Azure Policy.
- Vous devez activer le module complémentaire Azure Policy pour AKS. Pour plus d’informations, consultez Activer Azure Policy sur votre cluster AKS. Cela inclut l’inscription du
Microsoft.PolicyInsightsfournisseur de ressources dans votre abonnement.
Stratégies de mesures de sécurité du déploiement
Le tableau suivant répertorie les stratégies qui deviennent actives et les ressources Kubernetes qu’elles ciblent lorsque vous activez les mesures de sécurité de déploiement. Vous pouvez afficher les mesures de sécurité de déploiement actuellement disponibles dans le portail Azure en tant que définition Azure Policy ou dans les définitions intégrées d’Azure Policy pour Azure Kubernetes Service. L’intention de cette collection est de créer une liste commune et générique des meilleures pratiques applicables à la plupart des utilisateurs et cas d’usage.
| Stratégie de mesures de sécurité de déploiement | Résultat de la mutation s’il est disponible |
|---|---|
| Impossible de modifier des nœuds individuels | N/A |
| Les limites des ressources CPU et de mémoire des conteneurs de cluster Kubernetes ne doivent pas dépasser les limites spécifiées | Définit les limites de ressources du processeur sur 500m si elles ne sont pas définies et les limites de mémoire sur 500Mi si aucun chemin n’est présent |
| Doit avoir des règles d’anti-affinité ou topologieSpreadConstraintsSet | N/A |
| Aucune étiquette spécifique AKS | N/A |
| Les conteneurs de cluster Kubernetes doivent utiliser uniquement des fonctionnalités autorisées | N/A |
| Répulsions de pool de systèmes réservés | Supprime la répulsion CriticalAddonsOnly d’un pool de nœuds utilisateur s’il n’est pas défini. AKS utilise la teinte CriticalAddonsOnly pour empêcher les pods clients d’atteindre le pool système. Cette configuration garantit une séparation claire entre les composants AKS et les pods clients, et empêche l’éviction des pods clients qui ne tolèrent pas la répulsion CriticalAddonsOnly. |
| Vérifier que les conteneurs de cluster ont des sondes de préparation ou d’activité configurées | N/A |
| Les clusters Kubernetes doivent utiliser le pilote Container Storage Interface(CSI) StorageClass | N/A |
| Les services de cluster Kubernetes doivent utiliser des sélecteurs uniques | N/A |
| Les images conteneur de cluster Kubernetes ne doivent pas inclure la dernière balise d’image | N/A |
Si vous souhaitez envoyer une idée ou une demande de mesures de sécurité de déploiement, ouvrez un ticket dans le référentiel GitHub AKS et ajoutez-y [Deployment Safeguards request] au début du titre.
Normes de sécurité des pods dans les protections de déploiement
Remarque
Les normes de sécurité des pods de référence sont désormais activées par défaut dans AKS Automatic. Les normes de sécurité des pods de référence dans AKS Automatic ne peuvent pas être désactivées.
Les mesures de sécurité de déploiement prennent également en charge la possibilité d’activer les Normes de sécurité des pods de référence, restreintes et privilégiées. Pour vous assurer que vos charges de travail sont déployées avec succès, vérifiez que chaque manifeste est conforme aux exigences de sécurité des pods de référence ou restreintes. Par défaut, Azure Kubernetes Service utilise privileged Pod Security Standards.
| Policy | Message d'erreur | Réparer |
|---|---|---|
| AppArmor |
AppArmor annotation values must be undefined/nil, runtime/default, or localhost/* ou AppArmor profile type must be one of: undefined/nil, RuntimeDefault, or Localhost |
Supprimez toute spécification d’AppArmor. Kubernetes applique par défaut les paramètres apparmor. « Sur les hôtes pris en charge, le profil RuntimeDefault AppArmor est appliqué par défaut ». |
| Espaces de noms d’hôte |
Host network namespaces are disallowed: spec.hostNetwork is set to true' ou 'Host PID namespaces are disallowed: spec.hostPID is set to true' ou 'Host IPC namespaces are disallowed: spec.hostIPC is set to true' |
Définissez ces valeurs sur false ou supprimez la spécification des champs. |
| Conteneurs privilégiés | 'Privileged [ephemeral\|init\|N/A] containers are disallowed: spec.containers[*].securityContext.privileged is set to true' |
Définissez le champ securityContext.privileged approprié sur false ou supprimez le champ. |
| Capacités | Le message commence par 'Disallowed capabilities detected |
Supprimez la fonctionnalité affichée dans le manifeste du conteneur. |
| Volumes de type HostPath | HostPath volumes are forbidden under restricted security policy unless containers mounting them are from allowed images |
Supprimez le volume HostPath et le montage de volume. |
| Ports de l'hôte | HostPorts est interdit dans la stratégie de sécurité de base | Supprimez la spécification du port hôte du conteneur incriminé. |
| SELinux | SELinux type must be one of: undefined/empty, container_t, container_init_t, container_kvm_t, or container_engine_t |
Définissez le champ securityContext.seLinuxOptions.type du conteneur sur l’une des valeurs autorisées. |
| /proc Type de montage | ProcMount doit être non défini/nil ou « Default » dans spec.containers[*].securityContext.procMount | Définissez « * spec.containers[*].securityContext.procMount » sur « Par défaut » ou laissez-le non défini. |
| Seccomp | Seccomp profile must not be explicitly set to Unconfined. Allowed values are: undefined/nil, RuntimeDefault, or Localhost |
Définissez securityContext.seccompProfile.type sur le pod ou sur les conteneurs à l’une des valeurs autorisées. |
| Sysctls | Disallowed sysctl detected. Only baseline Kubernetes pod security standard sysctls are permitted |
Supprimez les sysctls non autorisés (consultez la spécification oss pour obtenir une liste spécifique). |
| Types de volumes (PSS Restreint uniquement) | Only the following volume types are allowed under restricted policy: configMap, csi, downwardAPI, emptyDir, ephemeral, persistentVolumeClaim, projected, secret |
Supprimez les volumes qui ne sont pas l’un des types autorisés. |
| Escalade de privilèges (PSS Restreint uniquement) | Privilege escalation must be set to false under restricted policy |
* spec.containers[*].securityContext.allowPrivilegeEscalation`` doit être explicitement défini sur false pour chaque conteneur, initContainer et ephemeralContainer. |
| Exécution en tant que non-root (PSS restreint uniquement) | Containers must not run as root user in spec.containers[*].securityContext.runAsNonRoot |
spec.containers[*].securityContext.runAsNonRoot doit être défini explicitement sur false pour chaque conteneur, initContainer et ephemeralContainer. |
| Exécution en tant qu'utilisateur non privilégié (PSS uniquement restreint) | 'Containers must not run as root user: spec.securityContext.runAsUser is set to 0' |
définissez securityContext.runAsUser sur une valeur différente de zéro, ou laissez-la non définie pour le niveau du pod, et pour chaque conteneur, initContainer et conteneur éphémère. |
| Seccomp (PSS uniquement restreint) | Seccomp profile must be "RuntimeDefault" or "Localhost" under restricted policy |
Définissez securityContext.seccompProfile.type sur le pod ou sur les conteneurs à l’une des valeurs autorisées. Cela diffère de la base de référence en fait que la stratégie restreinte n’autorise pas une valeur non définie. |
| Fonctionnalités (PSS restreint uniquement) |
All containers must drop ALL capabilities under restricted policy ou Only NET_BIND_SERVICE may be added to capabilities under restricted policy |
Tous les conteneurs doivent supprimer les fonctionnalités « ALL » et sont autorisés à ajouter « NET_BIND_SERVICE ». |
Activer les mesures de sécurité de déploiement
Remarque
L’utilisation du niveau Enforce des mesures de sécurité de déploiement signifie que vous optez pour les déploiements bloqués et mutés. Réfléchissez à la façon dont ces stratégies peuvent fonctionner avec votre cluster AKS avant d’activer Enforce.
Activer les mesures de sécurité de déploiement sur un cluster existant
Activez les mesures de sécurité de déploiement sur un cluster existant sur lequel le module complémentaire Azure Policy est activé à l’aide de la commande az aks safeguard create avec l’indicateur --level. Si vous souhaitez recevoir des avertissements de non-conformité, définissez --level sur Warn. Si vous souhaitez refuser ou muter tous les déploiements non conformes, définissez-le sur Enforce.
az aks safeguards create --resource-group <resource-group-name> --name <cluster-name> --level Enforce
Vous pouvez également activer les mesures de sécurité de déploiement à l’aide de l’indicateur --cluster et en spécifiant l’ID de ressource de cluster.
az aks safeguards create --cluster <ID> --level Enforce
Si vous souhaitez mettre à jour le niveau de mesures de sécurité du déploiement d’un cluster existant, exécutez la commande suivante avec la nouvelle valeur pour --level.
az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn
Exclure des espaces de noms
Vous pouvez également exclure certains espaces de noms des mesures de sécurité de déploiement. Lorsque vous excluez un espace de noms, l’activité dans cet espace de noms n’est pas affectée par les avertissements ou l’application des mesures de sécurité du déploiement.
Par exemple, pour exclure les espaces de noms ns1 et ns2, utilisez une liste séparée par des espaces des espaces de noms avec l’indicateur --excluded-ns, comme illustré dans l’exemple suivant :
az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn --excluded-ns ns1 ns2
Activer les Normes de Sécurité des Pods
Remarque
Azure Kubernetes Service (AKS) utilise Privileged les normes de sécurité des pods par défaut. Si vous souhaitez revenir à la configuration par défaut, définissez l’indicateur --pss-level à Privileged.
Pour activer les normes de sécurité pod dans les protections de déploiement, utilisez l’indicateur --pss-level pour sélectionner l’un des niveaux suivants : Baseline, Restrictedou Privileged.
az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn --pss-level <Baseline|Restricted|Privileged>
Mettre à jour votre version de protection du déploiement
Les mesures de sécurité de déploiement respectent le schéma de contrôle de version du module complémentaire AKS. Chaque nouvelle version d’une protection de déploiement sera publiée sous la forme d’une nouvelle version mineure dans AKS. Ces mises à jour seront communiquées via les notes de publication d’AKS GitHub et reflétées dans la table « Stratégies de mesures de sécurité du déploiement » dans notre documentation.
Pour en savoir plus sur le contrôle de version et les compléments AKS, consultez la documentation suivante : aks-component-versions et aks-versioning-for-addons.
Vérifier la conformité entre les clusters
Après avoir déployé votre manifeste Kubernetes, vous voyez des avertissements ou un message de déni potentiel dans votre interface CLI ou votre terminal si le cluster n’est pas conforme aux mesures de sécurité de déploiement, comme indiqué dans les exemples suivants :
Avertir
$ kubectl apply -f deployment.yaml
Warning: [azurepolicy-k8sazurev1antiaffinityrules-ceffa082711831ebffd1] Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing
deployment.apps/simple-web created
Appliquer
Avec les mutations de protection du déploiement, le niveau Enforce modifie vos ressources Kubernetes si applicable. Toutefois, vos ressources Kubernetes doivent toujours passer toutes les mesures de protection pour être déployées avec succès. Si des stratégies de protection échouent, votre ressource est refusée et ne sera pas déployée.
$ kubectl apply -f deployment.yaml
Error from server (Forbidden): error when creating "deployment.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-k8sazurev1antiaffinityrules-ceffa082711831ebffd1] Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing
Si vos ressources Kubernetes sont conformes aux protections de mutation applicables et répondent à toutes les autres exigences de protection, elles seront déployées avec succès, comme indiqué dans l’exemple suivant :
$ kubectl apply -f deployment.yaml
deployment.apps/simple-web created
Vérifier la conformité des différents clusters à l’aide du tableau de bord Azure Policy
Pour vérifier que les mesures de sécurité de déploiement ont été appliquées et pour vérifier la conformité de votre cluster, accédez à la page du portail Azure de votre cluster, puis sélectionnez Stratégies, puis accédez à Azure Policy.
Dans la liste des stratégies et des initiatives, sélectionnez l’initiative associée aux mesures de sécurité de déploiement. Un tableau de bord s’affiche, indiquant l’état de la conformité sur votre cluster AKS.
Remarque
Pour évaluer correctement la conformité sur votre cluster AKS, l’initiative Azure Policy doit être étendue au groupe de ressources de votre cluster.
Désactiver les mesures de sécurité de déploiement
Pour désactiver les mesures de sécurité de déploiement sur votre cluster, utilisez la commande delete.
az aks safeguards delete --resource-group <resource-group-name> --name <cluster-name>
Questions fréquentes (FAQ)
Puis-je créer mes propres mutations ?
Non. Si vous avez une idée de mesure de sécurité, ouvrez un problème dans le référentiel GitHub AKS et ajoutez [Deployment Safeguards request] au début du titre.
Puis-je choisir les mutations que je souhaite dans le mode Application ?
Non. Les mesures de sécurité de déploiement sont tout ou rien. Une fois que vous activez l’avertissement ou l’application, toutes les protections sont actives.
Pourquoi ma ressource de déploiement a-t-elle été admise, même si elle ne suivait pas les meilleures pratiques ?
Les mesures de sécurité de déploiement appliquent des normes de bonnes pratiques par le biais de contrôles Azure Policy et disposent de stratégies qui se valident vis-à-vis des ressources Kubernetes. Pour évaluer et appliquer des composants de cluster, Azure Policy étend Gatekeeper. L’application de Gatekeeper fonctionne également actuellement dans un modèlefail-open. Comme il n’existe aucune garantie que Gatekeeper répond à notre appel réseau, nous nous assurons que dans ce cas, la validation est ignorée afin que le refus ne bloque pas vos déploiements.
Pour plus d’informations, consultez Validation de charge de travail dans Gatekeeper.
Étapes suivantes
- En savoir plus sur les meilleures pratiques pour l’exploitation d’un cluster AKS.