Attention: atténuation des changements de comportement dans les interfaces de réseau virtuel, les instances, les serveurs bare metal et les partages de fichiers

Le 12 mars 2024, une fonction qui étend la prise en charge des interfaces de réseau virtuel a été mise à disposition dans le service VPC (Virtual Private Cloud). Si elle est utilisée dans votre compte, cette fonction introduit des changements de comportement dans les instances, les serveurs bare metal et les partages de fichiers. Ces modifications peuvent affecter votre automatisation ou vos flux de travaux pour la gestion de ces ressources.

Vous pouvez choisir de différer l'accès à cette fonctionnalité via l'assistance IBM. Les utilisateurs d'un compte dont l'accès est différé ne pourront pas créer d'instances ou de serveurs bare metal avec des interfaces de réseau virtuel. Si vous avez besoin de plus de temps pour évaluer, corriger et tester les modifications apportées aux interfaces de réseau virtuel, demandez un report pour vos comptes de production pendant que vous effectuez les atténuations à l'aide de vos comptes de test.

Si vous n'avez pas différé l'accès à cette fonction, lisez les conseils fournis même si vous ne prévoyez pas d'utiliser des interfaces de réseau virtuel.

Qu'est-ce qui a changé?

Les fonctions suivantes sont disponibles pour les interfaces de réseau virtuel:

  • Vous pouvez créer des instances et des serveurs bare metal avec des interfaces de réseau virtuel connectées à de nouvelles ressources enfant appelées connexions réseau. Vous pouvez spécifier un primary_network_attachment (à la place d'un primary_network_interface) et fournir l'identité d'une interface réseau virtuelle déjà créée ou un sous-réseau pour créer une nouvelle interface réseau virtuelle pour l'instance ou le serveur bare metal.
  • Les interfaces de réseau virtuel ont des cycles de vie qui sont indépendants des ressources auxquelles elles sont connectées. Vous pouvez mettre à jour la propriété auto_delete sur false pour permettre à une interface de réseau virtuel de persister au-delà du cycle de vie de son serveur ou de son instance bare metal d'origine et d'être reconnectée à un autre serveur ou à une autre instance bare metal.
  • Les interfaces de réseau virtuel prennent en charge les adresses IP secondaires. Vous pouvez ajouter et retirer des adresses IP réservées vers et depuis une interface de réseau virtuel.
  • Pour des raisons de compatibilité avec les clients existants, les instances et les serveurs bare metal dotés d'interfaces de réseau virtuel incluent une représentation en lecture seule de leurs connexions réseau et des interfaces de réseau virtuel en tant que ressources enfant d'interface réseau de style ancien. Découvrez la prise en charge des anciens clients d'API.
  • Pour les instances et les serveurs bare metal avec des interfaces de réseau virtuel, les droits IAM pour les options permettant l'usurpation d'adresse IP ou la désactivation de la conversion d'adresses réseau d'infrastructure sont gérés sur leurs interfaces de réseau virtuel connectées. Lors de la création ou de la mise à jour d'une interface réseau virtuelle, vous pouvez définir des valeurs autres que les valeurs par défaut pour les propriétés allow_ip_spoofing et enable_infrastructure_nat uniquement si vous disposez des droits is.virtual-network-interface.virtual-network-interface.manage-ip-spoofing et is.virtual-network-interface.virtual-network-interface.manage-infrastructure-nat IAM respectivement.
  • Vous pouvez utiliser des collecteurs de journaux de flux pour cibler des connexions réseau d'instance et des interfaces de réseau virtuel. Il n'y a pas de prise en charge des journaux de flux pour les serveurs bare metal et les cibles de montage partagées.

Pourquoi avons-nous fait ce changement?

Une interface de réseau virtuel fournit un mécanisme de consolidation des règles de réseau dans une ressource qui peut être conservée et réutilisée, avec un cycle de vie indépendant des ressources auxquelles elle est associée. Les droits IAM spécifiques au réseau sont gérés séparément des droits IAM de calcul. Lorsque de nouvelles fonctions de réseau sont publiées, elles sont mises à disposition via des interfaces de réseau virtuel, ce qui permet aux nouvelles fonctions de réseau de prendre en charge toutes les ressources auxquelles les interfaces de réseau virtuel peuvent se connecter.

Quels sont les effets de ce changement?

Sauf si vous avez un accès différé à cette fonction, votre compte est affecté par cette modification si vous disposez de clients d'API (tels que des automatisations personnalisées, des scripts d'audit ou des tableaux de bord) qui interagissent avec des instances, des serveurs bare metal, des interfaces réseau ou des partages de fichiers.

Ces opérations peuvent entraîner l'échec des clients d'API et des flux de travaux.

Quelles sont les actions que vous pouvez effectuer pour éviter un échec?

Les changements de comportement décrits dans cette section représentent les types de risques qui peuvent affecter votre code si votre compte n'a pas différé l'accès à cette fonction. Une personne de votre compte peut commencer à effectuer des opérations qui pourraient interrompre votre automatisation.

Comparez ces modifications à l'automatisation du client que vous avez créée. Utilisez ces conseils pour atténuer les changements de comportement qui peuvent entraîner des échecs du client API et du flux de travaux en mettant à jour et en testant la conception de votre automatisation.

Résolution des interfaces de réseau virtuel

Vous pouvez créer des instances et des serveurs bare metal avec des interfaces réseau virtuelles connectées à de nouvelles ressources enfant appelées connexions réseau. Les interfaces de réseau virtuel ont des cycles de vie qui sont indépendants des ressources auxquelles elles sont connectées, et les actions IAM spécifiques au réseau sont gérées sur les interfaces de réseau virtuel.

Changement de comportement 1

Pour une instance ou un serveur bare metal créé avec des connexions réseau, les ressources enfant de l'interface réseau de l'instance ou du serveur bare metal sont des représentations en lecture seule de ses connexions réseau (et de leurs interfaces réseau virtuelles associées).

Echec possible: les clients qui tentent de mettre à jour ces ressources en lecture seule échoueront.

Atténuation: Examinez le code client qui extrait et met à jour les ressources enfant network_interfaces des instances et des serveurs bare metal. Mettez à jour le code, si nécessaire, pour vérifier la présence d'une propriété primary_network_attachment dans l'instance ou le serveur bare metal. Modifiez la logique client pour mettre à jour à la place les ressources enfant network_attachments et les interfaces de réseau virtuel associées.

Changement de comportement 2

Les interfaces de réseau virtuel ont des cycles de vie qui sont indépendants des ressources auxquelles elles sont connectées. Une interface de réseau virtuel avec auto_delete défini sur false est conservée après la suppression de sa cible et les adresses IP réservées liées à l'interface de réseau virtuel restent liées. L'interface de réseau virtuel peut ensuite être connectée à une autre ressource.

Echec possible: les flux de travaux qui suppriment des instances, puis créent de nouvelles instances qui réutilisent les adresses IP réservées à partir des instances supprimées, peuvent échouer. Un échec se produit lors de la tentative de réutilisation d'une adresse IP réservée qui n'a pas été libérée car elle est toujours liée à une interface réseau virtuelle qui a survécu à une instance supprimée.

Atténuation: Examinez le code client pour connaître les hypothèses selon lesquelles les adresses IP réservées utilisées par les instances et les serveurs bare metal sont liées aux ressources enfant network_interfaces et seront toujours déliées immédiatement après la suppression d'une instance ou d'un serveur bare metal. Modifiez le client pour effectuer l'une des opérations suivantes:

  • Définissez la propriété auto_delete sur true sur les interfaces de réseau virtuel associées au network_attachments de l'instance ou du serveur bare metal avant de la supprimer.
  • Supprimer séparément toutes les interfaces de réseau virtuel avant que leurs adresses IP réservées ne soient réutilisées
  • Réutiliser les interfaces de réseau virtuel, qui réutilisent toutes les propriétés des interfaces de réseau virtuel, telles que primary_ip, tout ips secondaire, tout security_groups, etc.
Changement de comportement 3

Pour les instances et les serveurs bare metal avec des interfaces de réseau virtuel, les droits IAM pour les options permettant l'usurpation d'adresse IP ou la désactivation de la conversion d'adresses réseau d'infrastructure sont gérés sur les interfaces de réseau virtuel associées.

Incident possible: les clients et les flux de travaux qui mettent à jour les propriétés sur les interfaces réseau enfant pour permettre l'usurpation d'adresse IP ou la désactivation de la conversion d'adresses réseau d'infrastructure échoueront lorsque les instances ou les serveurs bare metal ont été créés avec des connexions réseau.

Atténuation: passez en revue le code client qui met à jour les propriétés allow_ip_spoofing ou enable_infrastructure_nat sur les ressources enfant network_interfaces. Mettez à jour le code pour vérifier la présence d'une propriété primary_network_attachment, ce qui signifie que les ressources enfant network_interfaces sont en lecture seule. Mettez à jour la logique client pour mettre à jour les propriétés allow_ip_spoofing ou enable_infrastructure_nat en fonction des besoins sur les interfaces de réseau virtuel associées au network_attachments de l'instance ou du serveur bare metal.

Résolution d'adresse IP

Changement de comportement

Les interfaces de réseau virtuel prennent en charge les adresses IP secondaires.

Echec possible: Un client qui tente d'énumérer des adresses IP pour une instance en extrayant le primary_ip.address sur les ressources enfant network_interfaces manquera les adresses IP secondaires si les network_interfaces sont des représentations compatibles en amont du network_attachments et de leurs interfaces de réseau virtuel associées.

Atténuation: passez en revue le code client qui énumère ou audite les adresses IP des instances et des serveurs bare metal. Mettez à jour votre code client pour vérifier la présence d'une propriété primary_network_attachment, qui signifie que l'instance ou le serveur bare metal possède network_attachments avec des interfaces de réseau virtuel associées. Mettez à jour la logique client pour extraire à la place toutes les propriétés address de la grappe ips sur chacune des interfaces de réseau virtuel associées.

Résolution du collecteur de journaux de flux

Changement de comportement

Les collecteurs de journaux de flux peuvent cibler des connexions réseau d'instance et des interfaces de réseau virtuel. Les journaux de flux sont collectés pour une interface de réseau virtuel lorsque l'interface est liée à une connexion réseau d'instance, et la convention de dénominationCloud Object Storage(COS) pour les journaux de flux collectés comporte l'identificateur de connexion réseau d'instance dans la zone vnic-id. Au cours de sa durée de vie, l'interface de réseau virtuel peut être connectée à plusieurs instances.

Échec possible : Les outils, les audits ou les procédures de dépannage qui analysent les journaux de flux collectés à partir de IBM Cloud® Object Storage buckets peuvent ne pas établir de corrélation entre les journaux et une interface réseau virtuelle.

Atténuation: passez en revue et mettez à jour les outils, l'audit ou les procédures de traitement des incidents qui créent des collecteurs de journaux de flux et analysent les journaux de flux. Lorsque vous ciblez une interface de réseau virtuel avec un collecteur de journaux de flux, assurez-vous que vos procédures d'analyse des journaux de flux tiennent compte du fait que le collecteur peut collecter des journaux de flux pour plusieurs instances au cours de la durée de vie de l'interface de réseau virtuel. L'identificateur de l'instance se trouve dans la section instance-id du nom du compartiment flow log Object Storage. Par conséquent, un nouveau compartiment Object Storage de journal de flux est créé lorsque le target d'une interface de réseau virtuel est mis à jour en associant l'interface de réseau virtuel à une nouvelle instance.

Suivi des activités et remédiation aux événements

Changement de comportement

La prise en charge élargie des interfaces réseau virtuelles permet d'ajouter de nombreux nouveaux événements de suivi des activités:

Défaillances possibles : Les outils clients et les processus d'audit qui n'ont pas été mis à jour pour les nouveaux événements de suivi des activités signaleront des séquences d'événements incomplètes.

Atténuation : Examinez vos outils qui consomment des événements de suivi d'activité et mettez-les à jour, le cas échéant, pour inclure les nouveaux événements. Il faut tenir compte du fait qu'aucun événement de suivi des activités n'est généré pour les représentations en lecture seule des pièces jointes du réseau.

Résolution de modèle d'instance

Changement de comportement 1

Un modèle d'instance peut être utilisé pour les instances avec des ressources enfant network_interfaces de style ancien ou pour les instances avec des ressources enfant network_attachments et des interfaces de réseau virtuel associées. Lors de la création d'une instance à partir d'un modèle d'instance, l'interface réseau ou le type de connexion doit correspondre à celui du modèle source.

Echec possible: les clients et les flux de travaux qui créent des instances à partir d'un modèle d'instance et qui remplacent les propriétés primary_network_interface ou network_interfaces échouent si le modèle concerne des instances avec un primary_network_attachment ou un network_attachments.

Atténuation: avant de créer une instance à partir d'un modèle, extrayez le modèle d'instance et déterminez si le modèle possède des propriétés primary_network_interface et network_interfaces ou des propriétés primary_network_attachment et network_attachments. Lors de la création d'une instance à partir du modèle, faites correspondre les propriétés de l'instance, selon les besoins, avec celles du modèle.

Changement de comportement 2

Un modèle d'instance peut être utilisé pour les instances avec des ressources enfant network_interfaces de style ancien ou pour les instances avec des ressources enfant network_attachments et des interfaces de réseau virtuel associées. Lors de la création d'un modèle d'instance à partir d'un modèle d'instance, l'interface réseau ou le type de pièce jointe doit correspondre à celui du modèle source.

Incident possible: les clients et les flux de travaux qui créent des modèles d'instance à partir d'un autre modèle d'instance et qui remplacent les propriétés primary_network_interface ou network_interfaces échouent si le modèle source concerne des instances avec primary_network_attachment et network_attachments.

Atténuation: avant de créer un modèle d'instance à partir d'un modèle source, extrayez le modèle source et déterminez si le modèle source possède des propriétés primary_network_interface et network_interfaces ou des propriétés primary_network_attachment et network_attachments. Lors de la création d'un nouveau modèle à partir du modèle source, faites correspondre les propriétés du nouveau modèle, selon les besoins, avec celles du modèle source.

Remarque: Vous êtes affecté par ces changements de comportement de modèle si l'une des conditions suivantes est vérifiée:

  • Un client API ou un utilisateur de votre compte crée un modèle comportant des connexions réseau et un client tente d'utiliser le nouveau modèle pour créer des instances ou des modèles avec des interfaces réseau
  • Un client tente d'utiliser un modèle comportant des interfaces réseau pour créer des instances ou des modèles avec des connexions réseau

Résolution du partage de fichiers

Changement de comportement

Les interfaces de réseau virtuel connectées aux cibles de montage de partage de fichiers peuvent avoir leur propriété auto_delete définie sur false. Lorsque la cible de montage de partage de fichiers associée à une telle interface de réseau virtuel est supprimée, l'interface de réseau virtuel n'est pas automatiquement supprimée. L'interface de réseau virtuel peut ensuite être réutilisée pour une autre ressource, telle qu'une autre cible de montage de partage de fichiers.

Echec possible: les flux de travaux qui suppriment des cibles de montage de partage de fichiers, puis suppriment des sous-réseaux, peuvent échouer. Un incident se produit lorsque les sous-réseaux contiennent des interfaces de réseau virtuel qui n'ont pas été automatiquement supprimées.

Atténuation: recherchez dans le code client les hypothèses selon lesquelles auto_delete est toujours true et mettez à jour la logique de suppression du client, si nécessaire, pour rechercher le virtual_network_interface associé à la cible de montage de partage. Sélectionnez ensuite l'une des actions suivantes :

  • Définissez la propriété auto_delete de l'interface de réseau virtuel sur true avant de supprimer la cible de montage de partage
  • Supprimer l'interface de réseau virtuel dans une étape de suivi
  • Préserver l'interface de réseau virtuel pour une réutilisation ultérieure avec la nouvelle cible de montage de partage