Application à un cas concret : le rattachement d’un volume EBS

Pour avoir une meilleure idée du nombre de composants du Système Nitro qui fonctionnent ensemble, examinons ce qu’il se passe lorsqu'un client effectue un appel à l'API EC2 qui modifie l'état de fonctionnement de son instance EC2 sur un Système Nitro. Nous examinerons en particulier le cas où un client attache un volume EBS crypté existant à une instance en cours d'exécution.

Dans un premier temps, le client utilise l'AWS Command Line Interface (AWS CLI), le SDK AWS ou la AWS Management Console pour appeler la commande AttachVolume, en ciblant l'instance choisie. Après avoir vérifié que l'identité IAM du client est authentifiée et autorisée à exécuter la commande AttachVolume, l'appel d'API est traité par un ensemble de microservices au sein des plans de contrôle EC2 et EBS. Au final, les services du plan de contrôle font appel à un ensemble défini d'API réseau, fournies par le Contrôleur Nitro, chiffrées et authentifiées, avec les informations requises pour allouer les ressources nécessaires au rattachement du volume. Plusieurs services sont impliqués dans cette opération, chaque microservice prenant en charge des tâches distinctes qui limitent l'étendue de l'accès aux API du Contrôleur Nitro.

Le plan de contrôle EC2 alloue les ressources du périphérique PCIe de la carte Nitro pour EBS qui sont nécessaires aux opérations de lecture et d'écriture sur le volume logique EBS (soit une fonction virtuelle NVMe pour une instance virtualisée, soit une fonction physique NVMe pour une instance « bare metal »). Le plan de contrôle EBS fournit les informations nécessaires pour se connecter aux serveurs EBS hébergeant les données chiffrées du volume sur le réseau, ainsi qu'une copie chiffrée de la clé de données du volume qui est stockée sous forme de métadonnées du volume. La clé de données chiffrée est protégée par une clé AWS KMS présente uniquement dans AWS Key Management Service (AWS KMS). Par conséquent, dans le cadre du processus d'attachement du volume, la clé chiffrée doit être envoyée à AWS KMS pour être déchiffrée.

En supposant que l'identité IAM du client à l'origine de la commande AttachVolume soit également autorisée à exécuter une commande Decrypt dans AWS KMS pour la clé AWS KMS en question, la clé de données du volume chiffré sera déchiffrée. L'accès du Système Nitro à cette opération est protégé par AWS KMS Grants et par les sessions d'accès IAM Forward. (Reportez-vous à cette explication des IAM Forward Access Sessions dans le contexte d'Elastic Load Balancing, d'AWS Certificate Manager et d', dans une présentation de Colm MacCárthaigh, vice-président et ingénieur émérite chez AWS.)

Ensemble, ces mécanismes garantissent de manière cryptographique que le Système Nitro n’est autorisé à utiliser une clé d’un client gérée par AWS KMS que lorsque le client a récemment autorisé et authentifié cet accès. Le Système Nitro n'est pas autorisé à utiliser les clés gérées par AWS KMS de manière ponctuelle ou en l'absence d'une autorisation récente du client.

Après avoir été déchiffrée dans AWS KMS et avant d'être envoyée au Contrôleur Nitro à l'aide d'une connexion réseau TLS (Transport Layer Security) chiffrée, AWS KMS chiffre à nouveau la clé de données à l'aide d'une clé publique qui sert d'identité numérique cryptographique pour le serveur hôte Nitro de production en question. Cette clé publique a été envoyée avec la clé de données du volume chiffré par le plan de contrôle EBS à AWS KMS. Par conséquent, en plus du chiffrement de l'intégralité du message en transit par TLS, la clé de données est également chiffrée de manière asymétrique dans le message, c'est-à-dire qu’elle est chiffrée deux fois. Seule la Carte Nitro de cet hôte de production spécifique supportant l'environnement informatique de ce client spécifique possède la clé privée nécessaire pour déchiffrer la clé de données chiffrée. Une fois déchiffrée localement, la clé de données en clair est stockée uniquement dans la mémoire volatile de cette Carte Nitro, pour la durée de l’attachement et de l'utilisation du volume.

La Carte Nitro EBS est maintenant prête à présenter le volume EBS à l'instance EC2 via une connexion PCIe à une interface NVMe. Lorsque l'hôte est configuré pour utiliser l'Hyperviseur Nitro, le Contrôleur Nitro envoie un message via l'interface PCIe pour demander à l'Hyperviseur Nitro d'attribuer la fonction virtuelle NVMe pour ce volume EBS à l'instance EC2 appropriée. L'Hyperviseur envoie ensuite un événement de connexion à chaud du matériel virtuel à la machine virtuelle pour avertir le logiciel système du client qu'un nouveau périphérique de stockage en mode bloc NVMe est disponible. Dans le cas d'une instance « bare metal », la Carte Nitro pour EBS signale un événement de connexion à chaud PCIe directement au processeur du serveur, et le logiciel système du client exécuté sur le processeur gère l'événement de connexion à chaud PCIe du périphérique NVMe, comme il le ferait sur n'importe quel autre serveur.

À ce stade, le système d'exploitation de l'instance client s'exécutant en tant qu'invité virtuel ou en tant qu'instance « bare metal » interagit avec un périphérique NVMe présenté par la Carte Nitro pour EBS via l'interface PCIe. Cette interaction se produit soit sous la forme d'une fonction SR-IOV dans le cas d'instances EC2 virtuelles, soit sous la forme d'une fonction physique PCIe dans le cas d'instances EC2 « bare metal ». Les commandes NVMe envoyées via l'interface PCIe sont traitées par le microprogramme exécuté sur la Carte Nitro pour EBS, qui interagit à son tour avec le service EBS via l'interface réseau intégrée du SoC Nitro. Comme indiqué précédemment, la Carte Nitro EBS est également capable de décharger les opérations cryptographiques des volumes EBS chiffrés au format AES-256 XTS, de sorte que chaque bloc de données client soit entièrement chiffré avant de quitter la Carte Nitro, sans impact sur les performances. Un client peut également choisir d'utiliser un système de fichiers chiffré au niveau du système d'exploitation afin que toutes les données client soient entièrement cryptées avant d'être écrites ou transmises sur la Carte Nitro pour EBS. Cette approche met en place une couche de chiffrement supplémentaire pour les données EBS, à la fois lors du transit et dans le système de stockage EBS.