1.4. Changements techniques notables
OpenShift Container Platform 4.12 introduit les changements techniques notables suivants.
Points d'extrémité régionaux du service de jetons de sécurité AWS
L'utilitaire Cloud Credential Operator (ccoctl) crée désormais des secrets qui utilisent des points d'extrémité régionaux pour le service de jetons de sécurité AWS (AWS STS). Cette approche est conforme aux meilleures pratiques recommandées par AWS.
Paramètre du répertoire des demandes d'informations d'identification pour la suppression des ressources GCP à l'aide de l'utilitaire Cloud Credential Operator
Avec cette version, lorsque vous supprimez des ressources GCP avec l'utilitaire Cloud Credential Operator, vous devez spécifier le répertoire contenant les fichiers des objets du composant CredentialsRequest.
Application restreinte à l'avenir pour l'admission à la sécurité des pods
Actuellement, les violations de la sécurité des pods sont affichées sous forme d'avertissements et enregistrées dans les journaux d'audit, mais n'entraînent pas le rejet du pod.
Une application restreinte globale pour l'admission de la sécurité des pods est actuellement prévue pour la prochaine version mineure d'OpenShift Container Platform. Lorsque cette application restreinte est activée, les pods présentant des violations de la sécurité des pods seront rejetés.
Pour vous préparer à ce changement, assurez-vous que vos charges de travail correspondent au profil d'admission de sécurité du pod qui s'applique à elles. Les charges de travail qui ne sont pas configurées conformément aux normes de sécurité appliquées définies globalement ou au niveau de l'espace de noms seront rejetées. Le SCC restricted-v2 admet les charges de travail conformément à la définition de Kubernetes restreint.
Si vous recevez des violations de la sécurité des pods, consultez les ressources suivantes :
- Reportez-vous à la section Identification des violations de sécurité des pods pour savoir comment identifier les charges de travail à l'origine des violations de sécurité des pods.
Voir Synchronisation des contraintes de contexte de sécurité avec les normes de sécurité des pod s pour comprendre quand la synchronisation des étiquettes d'admission à la sécurité des pods est effectuée. Les étiquettes d'admission à la sécurité des pods ne sont pas synchronisées dans certaines situations, notamment dans les cas suivants :
-
La charge de travail s'exécute dans un espace de noms créé par le système et préfixé par
openshift-. - La charge de travail s'exécute sur un pod qui a été créé directement sans contrôleur de pod.
-
La charge de travail s'exécute dans un espace de noms créé par le système et préfixé par
-
Si nécessaire, vous pouvez définir un profil d'admission personnalisé pour l'espace de noms ou le pod en définissant l'étiquette
pod-security.kubernetes.io/enforce.
Cataloguer les sources et les pods restreints, appliquer les règles d'admission à la sécurité
Les sources de catalogue construites en utilisant le format de catalogue basé sur SQLite et une version de l'outil CLI opm publiée avant OpenShift Container Platform 4.11 ne peuvent pas fonctionner sous l'application de la sécurité des pods restreints.
Dans OpenShift Container Platform 4.12, les espaces de noms n'ont pas de mise en œuvre de la sécurité restreinte des pods par défaut et le mode de sécurité de la source du catalogue par défaut est défini sur legacy.
Si vous ne souhaitez pas exécuter vos pods de source de catalogue basés sur SQLite dans le cadre d'une application restreinte de la sécurité des pods, vous n'avez pas besoin de mettre à jour votre source de catalogue dans OpenShift Container Platform 4.12. Cependant, pour garantir l'exécution de vos sources de catalogue dans les futures versions d'OpenShift Container Platform, vous devez mettre à jour vos sources de catalogue pour qu'elles s'exécutent dans le cadre d'une application restreinte de la sécurité des pods.
En tant qu'auteur de catalogue, vous pouvez activer la compatibilité avec l'application de la sécurité des pods restreints en effectuant l'une des actions suivantes :
- Migrez votre catalogue vers le format de catalogue basé sur les fichiers.
-
Mettez à jour votre image de catalogue avec une version de l'outil
opmCLI publiée avec OpenShift Container Platform 4.11 ou une version ultérieure.
Si vous ne souhaitez pas mettre à jour l'image du catalogue de votre base de données SQLite ou migrer votre catalogue vers le format de catalogue basé sur des fichiers, vous pouvez configurer votre catalogue pour qu'il s'exécute avec des autorisations élevées.
Pour plus d'informations, voir Sources du catalogue et admission de la sécurité des pods.
Opérateur SDK 1.25.4
OpenShift Container Platform 4.12 supporte Operator SDK 1.25.4. Voir Installer l'Operator SDK CLI pour installer ou mettre à jour cette dernière version.
Operator SDK 1.25.4 prend en charge Kubernetes 1.25.
Pour plus d'informations, voir Beta APIs removed from Kubernetes 1.25 et Validating bundle manifests for APIs removed from Kubernetes 1.25.
Si vous avez des projets Operator qui ont été précédemment créés ou maintenus avec Operator SDK 1.22.0, mettez à jour vos projets pour maintenir la compatibilité avec Operator SDK 1.25.4.
L'opérateur LVM s'appelle désormais Logical Volume Manager Storage
L'opérateur LVM qui était précédemment livré avec Red Hat OpenShift Data Foundation nécessite une installation via OpenShift Data Foundation. Dans OpenShift Container Platform v4.12, l'opérateur LVM a été renommé Logical Volume Manager Storage. Désormais, vous l'installez en tant qu'opérateur autonome à partir du catalogue OpenShift Operator. Logical Volume Manager Storage permet le provisionnement dynamique du stockage en bloc sur un cluster OpenShift unique à nœud unique et à ressources limitées.
