Migrer depuis les anciennes politiques de sécurité des pods (PSP) - Amazon EKS

Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions contribueront à améliorer notre guide de l'utilisateur pour tous.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Migrer depuis les anciennes politiques de sécurité des pods (PSP)

PodSecurityPolicyétait obsolète dans Kubernetes1.21 et a été supprimé dans Kubernetes 1.25. Si vous l'utilisez PodSecurityPolicy dans votre cluster, vous devez migrer vers le module intégré Kubernetes Normes de sécurité des pods (PSS) ou vers une policy-as-code solution avant de mettre à niveau votre cluster vers la version *1.25 afin d'éviter toute interruption de vos charges de travail.* Sélectionnez l'une des questions fréquemment posées pour en savoir plus.

PodSecurityPolicyest un contrôleur d'admission intégré qui permet à un administrateur de cluster de contrôler les aspects sensibles à la sécurité de Pod spécification. Si un Pod répond aux exigences de ses PSP, le Pod est admis dans le cluster comme d'habitude. Si un Pod ne répond pas aux PSP les exigences, les Pod est rejeté et ne peut pas être exécuté.

Il s'agit d'une modification en amont du Kubernetes projet, et non une modification apportée sur AmazonEKS. PSP a été déprécié dans Kubernetes 1.21et retiré dans Kubernetes 1.25. Le Kubernetes la communauté a identifié de sérieux problèmes d'utilisabilité avec PSP. Il s'agissait notamment de l'octroi accidentel d'autorisations plus larges que prévu et de la difficulté à inspecter lesquelles PSPs s'appliquent dans une situation donnée. La résolution de ces problèmes nécessitait des changements radicaux. C'est la principale raison pour laquelle le Kubernetes la communauté a décidé de supprimer PSP.

Pour vérifier si vous utilisez PSPs dans votre cluster, vous pouvez exécuter la commande suivante :

kubectl get psp

Pour voir le Pods que le PSPs si votre cluster a un impact, exécutez la commande suivante. Cette commande génère le Pod nom, espace de noms et PSPs:

kubectl get pod -A -o jsonpath='{range.items[?(@.metadata.annotations.kubernetes\.io/psp)]}{.metadata.name}{"\t"}{.metadata.namespace}{"\t"}{.metadata.annotations.kubernetes\.io/psp}{"\n"}'

Avant de procéder à la mise à niveau de votre cluster vers1.25, vous devez migrer votre PSPs à l'une ou l'autre de ces alternatives :

  • Kubernetes PSS.

  • Policy-as-code solutions du Kubernetes environnement.

En réponse à la PSP la dépréciation et le besoin permanent de contrôler Pod sécurité dès le départ, le Kubernetes la communauté a créé une solution intégrée avec (PSS) et Pod Security Admission (PSA). Le PSA webhook implémente les contrôles définis dans le PSS.

Vous pouvez consulter les meilleures pratiques en matière de migration PSPs vers le intégré PSS dans le Guide des EKS meilleures pratiques. Nous vous recommandons également de consulter notre blog sur la mise en œuvre des normes de sécurité des pods sur Amazon EKS. Les références supplémentaires incluent Migrate from PodSecurityPolicy to the built-in PodSecurity Admission Controller et Mapping PodSecurityPolicies to Pod Security Standards.

Policy-as-code les solutions fournissent des garde-fous pour guider les utilisateurs du cluster et empêchent les comportements indésirables grâce à des contrôles automatisés prescrits. Policy-as-codeles solutions utilisent généralement les contrôleurs d'admission dynamiques Kubernetes pour intercepter les Kubernetes APIflux de demandes au serveur à l'aide d'un appel webhook. Policy-as-codeles solutions modifient et valident les charges utiles des demandes en fonction de politiques écrites et stockées sous forme de code.

Il existe plusieurs policy-as-code solutions open source disponibles pour Kubernetes. Pour passer en revue les meilleures pratiques en matière de migration PSPs pour policy-as-code trouver une solution, consultez la olicy-as-code section P de la page Pod Security sur GitHub.

EKSClusters Amazon avec Kubernetes version 1.13 ou supérieure ont une valeur par défaut PSP ça s'appelleeks.privileged. Cette politique est créée dans les clusters 1.24 et les clusters de version antérieure. Il n'est pas utilisé dans les clusters 1.25 et versions ultérieures. Amazon migre EKS automatiquement ce fichier PSP à un PSSapplication basée sur l'application. Aucune action de votre part n'est nécessaire.

Non. En outreeks.privileged, qui est un PSP créé par AmazonEKS, aucune modification n'est apportée aux autres PSPs dans votre cluster lors de la mise à niveau vers1.25.

Non. Amazon n'EKSempêchera pas la mise à jour de la version d'un cluster 1.25 si vous n'avez pas migré depuis PSP encore.

Lorsqu'un cluster contenant un PSP est mis à niveau vers Kubernetes version1.25, le API serveur ne reconnaît pas le PSP ressource dans1.25. Cela peut entraîner Pods obtenir des étendues de sécurité incorrectes. Pour une liste exhaustive des implications, voir PodSecurityPolicy Migrer depuis le contrôleur PodSecurity d'admission intégré.

Nous ne prévoyons aucun impact spécifique sur les charges de travail Windows. PodSecurityContext possède un champ appelé windowsOptions dans le PodSpec v1 API pour Windows Pods. Cela utilise PSS dans Kubernetes 1.25. Pour plus d'informations et les meilleures pratiques en matière d'application PSS pour les charges de travail Windows, consultez le Guide des EKS meilleures pratiques et Kubernetes documentation.