Gestion des identités matérielles approuvées
Le service Gestion des identités matérielles approuvées gère la gestion du cache des certificats pour tous les environnements d’exécution approuvés (TEE) qui résident dans Azure. Il fournit également des informations de base de calcul fiable (TCB) pour appliquer une base de référence minimale pour les solutions d’attestation.
Gestion des identités matérielles approuvées et interactions d’attestation
La gestion des identités matérielles approuvées définit la ligne de base en matière de sécurité Azure pour les nœuds d’informatique confidentielle Azure (ACC) et met en cache la documentation et les ressources des fournisseurs TEE. Les services d’attestation et les nœuds ACC peuvent utiliser les informations mises en cache pour valider les TEE. Le diagramme suivant montre les interactions entre un service ou un nœud d'attestation, Gestion des identités matérielles approuvées et un hôte d'enclave.
Forum aux questions
Comment faire pour utiliser la gestion des identités matérielles approuvées avec des processeurs Intel ?
Pour générer des devis Intel SGX et Intel TDX, la bibliothèque de génération de devis Intel (QGL) doit accéder au matériel de génération/vérification de devis. Ce matériel, en tout ou partie, doit être récupéré auprès de la Gestion des identités matérielles approuvées. Vous pouvez l’extraire à l’aide de la bibliothèque du fournisseur de devis Intel (QPL) ou de la bibliothèque cliente Azure Data Center Attestation Primitives (DCAP).
La date de « prochaine mise à jour » de l’API du service de mise en cache interne Azure, utilisée par Azure Attestation, semble obsolète. Est-elle toujours opérationnelle et peut-elle être utilisée ?
Le champ tcbinfo contient les informations TCB. Le service Gestion des identités matérielles approuvées fournit par défaut des informations plus anciennes tcbinfo. La mise à jour vers la dernière version du champ tcbinfo d’Intel entraînerait des échecs d’attestation pour les clients qui n’ont pas migré vers le dernier kit SDK Intel et pourrait entraîner des pannes.
Ouvrez le SDK Enclave et Azure Attestation ne prêtera pas attention à la date nextUpdate. En revanche, il passera l’attestation avec succès.
Qu’est-ce que la bibliothèque Azure DCAP ?
La bibliothèque Azure Data Center Attestation Primitives (DCAP), un remplacement d’Intel Quote Provider Library (QPL), extrait la documentation de génération de devis et la documentation de validation de devis directement à partir du service Gestion des identités matérielles approuvées. L’extraction de la documentation directement à partir du service Gestion des identités matérielles approuvées garantit que tous les hôtes Azure disposent de la documentation disponible dans le cloud Azure pour réduire les dépendances externes. La version actuelle recommandée de la bibliothèque DCAP est 1.11.2.
Où puis-je télécharger la dernière bibliothèque Azure DCAP ?
Utilisez les liens suivants pour télécharger les packages :
Pour les versions plus récentes d’Ubuntu (par exemple, Ubuntu 22.04), vous devez utiliser le Intel QPL.
Pourquoi Gestion des identités matérielles approuvées et Intel ont-ils des bases de référence différentes ?
Gestion des identités matérielles approuvées et Intel fournissent différents niveaux de ligne de base de la base d’informatique de confiance. Lorsque les clients supposent qu’Intel dispose des dernières bases de référence, ils doivent s’assurer que toutes les exigences sont satisfaites. Cette approche peut entraîner une rupture si les clients n’ont pas mis à jour les exigences spécifiées.
Gestion des identités matérielles approuvées adopte une approche plus lente de mise à jour de la ligne de base TCB pour permettre aux clients d’apporter les modifications nécessaires à leur propre rythme. Bien que cette approche fournisse une base de référence TCB plus ancienne, les clients ne connaîtront pas de rupture s’ils n’ont pas satisfait aux exigences de la nouvelle base de référence TCB. C’est pourquoi la base de référence TCB de Gestion des identités matérielles approuvées est une version différente de la base de référence d’Intel. Le client est notre priorité et nous voulons lui permettre de satisfaire aux conditions imposées par la nouvelle ligne de base TCB à son propre rythme, au lieu de le forcer à se mettre à jour et de leur causer un désavantage, ce qui nécessiterait une nouvelle hiérarchisation de ses flux de travail.
Avec les processeurs Intel Xeon E, je pouvais obtenir mes certificats directement à partir du PCS Intel. Pourquoi, avec les processeurs Intel Xeon Scalable à partir de la 4e génération, dois-je obtenir les certificats de Trusted Hardware Identity Management ? Et comment puis-je récupérer ces certificats ?
À compter de la 4e génération des processeurs Intel® Xeon® Scalable Processors, Azure effectue une inscription indirecte auprès du service d’inscription d’Intel à l’aide du Manifeste de plateforme et stocke le certificat PCK obtenu dans le service THIM (Trusted Hardware Identity Management) qu’Azure utilise pour l’inscription indirecte, car le service d’inscription d’Intel ne stocke pas les clés racines d’une plateforme dans ce cas et cela est reflété par false dans l’indicateur CachedKeys dans les certificats PCK.
Comme l’inscription indirecte est utilisée, toute communication ultérieure avec Intel PCS nécessiterait le manifeste de plateforme, qu’Azure ne fournit pas aux machines virtuelles.
Au lieu de cela, les machines virtuelles doivent contacter THIM pour recevoir des certificats PCK.
Pour récupérer un certificat PCK, vous pouvez utiliser le Intel QPL ou la bibliothèque Azure DCAP.
Comment faire pour utiliser Intel QPL avec Gestion des identités matérielles approuvées ?
Les clients peuvent souhaiter avoir la possibilité d’utiliser Intel QPL pour interagir avec Gestion des identités matérielles approuvées sans avoir à télécharger une autre dépendance à partir de Microsoft (c’est-à-dire, la bibliothèque de client Azure DCAP). Les clients qui souhaitent utiliser Intel QPL avec le service Gestion des identités matérielles approuvées doivent ajuster le fichier de configuration Intel QPL, sgx_default_qcnl.conf.
La documentation de génération/vérification de devis qui est utilisée pour générer les devis Intel SGX ou Intel TDX peuvent être divisée en :
- Certificat PCK. Pour le récupérer, les clients doivent utiliser un point de terminaison gestion des identités matérielles approuvées.
- Toutes les autres documentations de génération/vérification de devis. Pour les récupérer, les clients peuvent utiliser un point de terminaison de gestion des identités matérielles approuvées ou un point de terminaison du service de certification d’approvisionnement Intel (PCS).
Le fichier de configuration Intel QPL (sgx_default_qcnl.conf) contient trois clés utilisées pour définir les points de terminaison des matériaux. La clé pccs_url définit le point de terminaison utilisé pour récupérer les certificats PCK. La clé collateral_service peut être utilisée pour définir le point de terminaison utilisé pour récupérer toutes les autres documentations de génération/vérification de devis. Si la clé collateral_service n’est pas définie, tous les matériaux de vérification de devis sont récupérés à partir du point de terminaison défini avec la clé pccs_url.
Le tableau suivant explique comment ces clés peuvent être définies.
| Nom | Points de terminaison possibles |
|---|---|
pccs_url |
Point de terminaison Gestion des identités matérielles approuvées : https://global.acccache.azure.net/sgx/certification/v3. |
collateral_service |
Point de terminaison de gestion des identités matérielles approuvé (https://global.acccache.azure.net/sgx/certification/v3) ou point de terminaison Intel PCS. Le fichier sgx_default_qcnl.conf répertorie toujours le point de terminaison le plus à jour dans la clé collateral_service. |
L’extrait de code suivant provient d’un exemple de fichier de configuration Intel QPL :
{
"pccs_url": "https://global.acccache.azure.net/sgx/certification/v3/",
"use_secure_cert": true,
"collateral_service": "https://global.acccache.azure.net/sgx/certification/v3/",
"pccs_api_version": "3.1",
"retry_times": 6,
"retry_delay": 5,
"local_pck_url": "http://169.254.169.254/metadata/THIM/sgx/certification/v3/",
"pck_cache_expire_hours": 24,
"verify_collateral_cache_expire_hours": 24,
"custom_request_options": {
"get_cert": {
"headers": {
"metadata": "true"
},
"params": {
"api-version": "2021-07-22-preview"
}
}
}
}
Les procédures suivantes expliquent comment modifier le fichier de configuration Intel QPL et activer les modifications.
Sur Windows
Apportez des modifications au fichier de configuration.
Vérifiez que le fichier dispose d’autorisations de lecture sur le fichier à partir de l’emplacement et de la clé/valeur de registre suivants :
[HKEY_LOCAL_MACHINE\SOFTWARE\Intel\SGX\QCNL] "CONFIG_FILE"="<Full File Path>"Redémarrez le service AESMD. Par exemple, ouvrez PowerShell en tant qu’administrateur et utilisez les commandes suivantes :
Restart-Service -Name "AESMService" -ErrorAction Stop Get-Service -Name "AESMService"
Sur Linux
Apportez des modifications au fichier de configuration. Par exemple, vous pouvez utiliser Vim pour les modifications via la commande suivante :
sudo vim /etc/sgx_default_qcnl.confRedémarrez le service AESMD. Ouvrez un terminal et exécutez les commandes suivantes :
sudo systemctl restart aesmd systemctl status aesmd
Comment faire demander des garanties dans une machine virtuelle confidentielle ?
Utilisez l’exemple suivant dans un invité CVM pour demander la documentation et les ressources AMD qui incluent le certificat VCEK et la chaîne de certificats. Pour plus d’informations sur cette documentation et ressources et son origine, consultez Certificat VCEK (Versioned Chip Endorsement Key) et spécification de l’interface KDS.
Paramètres URI
GET "http://169.254.169.254/metadata/THIM/amd/certification"
Corps de la demande
| Nom | Type | Description |
|---|---|---|
Metadata |
Boolean | La définition de la valeur True permet de retourner la documentation et les ressources. |
Exemple de requête
curl GET "http://169.254.169.254/metadata/THIM/amd/certification" -H "Metadata: true"
Réponses
| Nom | Description |
|---|---|
200 OK |
Répertorie les garanties disponibles dans le corps HTTP au format JSON |
Other Status Codes |
Décrit la raison de l’échec de l’opération |
Définitions
| Clé | Description |
|---|---|
VcekCert |
Certificat X.509v3 tel que défini dans RFC 5280 |
tcbm |
Trusted Computing Base |
certificateChain |
Certificats de clé SEV AMD (ASK) et de clé racine AMD (ARK) |
Comment faire demander une garantie AMD dans un conteneur Azure Kubernetes Service sur un nœud CVM ?
Procédez comme suit pour demander une garantie AMD dans un conteneur confidentiel :
Commencez par créer un cluster Azure Kubernetes Service (AKS) sur un nœud CVM ou en ajoutant un pool de nœuds CVM à un cluster existant :
Créez un cluster AKS sur un nœud CVM :
Créez un groupe de ressources dans l'une des régions prises en charge par CVM :
az group create --resource-group <RG_NAME> --location <LOCATION>Créez un cluster AKS avec un nœud CVM dans le groupe de ressources :
az aks create --name <CLUSTER_NAME> --resource-group <RG_NAME> -l <LOCATION> --node-vm-size Standard_DC4as_v5 --nodepool-name <POOL_NAME> --node-count 1Configurez kubectl pour se connecter au cluster :
az aks get-credentials --resource-group <RG_NAME> --name <CLUSTER_NAME>
Ajoutez un pool de nœuds CVM au cluster AKS existant :
az aks nodepool add --cluster-name <CLUSTER_NAME> --resource-group <RG_NAME> --name <POOL_NAME > --node-vm-size Standard_DC4as_v5 --node-count 1
Pour vérifier la connexion à votre cluster, exécutez la commande
kubectl get. Cette commande renvoie la liste des nœuds de cluster.kubectl get nodesL’exemple de sortie suivant montre le nœud unique créé au cours des étapes précédentes. Assurez-vous que l’état du nœud est
Ready.NOM STATUT ROLES AGE VERSION aks-nodepool1-31718369-0 Ready agent 6m44s v1.12.8 Créez un fichier curl.yaml avec le contenu suivant. Il définit un travail qui exécute un conteneur curl pour extraire la garantie AMD à partir du point de terminaison Gestion des identités matérielles approuvées. Pour plus d’informations sur les travaux Kubernetes, voir la documentation de Kubernetes.
apiVersion: batch/v1 kind: Job metadata: name: curl spec: template: metadata: labels: app: curl spec: nodeSelector: kubernetes.azure.com/security-type: ConfidentialVM containers: - name: curlcontainer image: alpine/curl:3.14 imagePullPolicy: IfNotPresent args: ["-H", "Metadata:true", "http://169.254.169.254/metadata/THIM/amd/certification"] restartPolicy: "Never"Le fichier curl.yaml contient les arguments suivants.
Nom Type Description MetadataBoolean La définition de la valeur Truepermet de retourner la documentation et les ressources.Exécutez le travail en appliquant le fichier curl.yaml :
kubectl apply -f curl.yamlVérifiez et attendez que le pod termine son travail :
kubectl get podsVoici un exemple de réponse :
Nom Ready Statut Restarts Age Curl-w7nt8 0/1 Effectué 0 72 s Exécutez la commande suivante pour obtenir les journaux des travaux et vérifier si cela fonctionne. Une sortie réussie doit inclure
vcekCert,tcbm, etcertificateChain.kubectl logs job/curl
Étapes suivantes
- En savoir plus sur la documentation Azure Attestation.
- Découvrez-en plus sur l’informatique confidentielle Azure.
Commentaires
Bientôt disponible : Tout au long de l’année 2024, nous abandonnerons progressivement le mécanisme de retour d’information GitHub Issues pour le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez : https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour