

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Versioni IMDS su Snowball Edge
<a name="imds-versions"></a>

È possibile accedere ai metadati dell'istanza da un'istanza in esecuzione utilizzando IMDS versione 2 o IMDS versione 1:
+ Instance Metadata Service versione 2 (IMDSv2), un metodo orientato alla sessione
+ Instance Metadata Service versione 1 ()IMDSv1, un metodo di richiesta-risposta

A seconda della versione del software Snow, puoi utilizzare o IMDSv1 entrambi IMDSv2. Ciò dipende anche dal tipo di AMI in esecuzione nell'istanza EC2 -compatible. Alcune AMIs, come quelle che eseguono Ubuntu 20.04, richiedono. IMDSv2 Il servizio di metadati delle istanze distingue tra IMDSv1 e IMDSv2 richieste in base alla presenza o alle intestazioni`PUT`. `GET` IMDSv2utilizza entrambe queste intestazioni. IMDSv1 utilizza solo l'`GET`intestazione.

AWS incoraggia l'uso di IMDSv2 piuttosto che IMDSv1 perché IMDSv2 include una maggiore sicurezza. Per ulteriori informazioni, consulta [Aggiungere una difesa approfondita contro firewall aperti, reverse proxy e vulnerabilità SSRF con](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/) miglioramenti all'Instance Metadata Service. EC2 

## IMDSv2 su uno Snowball Edge
<a name="imdsv2"></a>

Quando si utilizza IMDSv2 per richiedere i metadati dell'istanza, la richiesta deve seguire queste regole:

1. Utilizza una richiesta `PUT` per inizializzare una sessione al servizio di metadati dell'istanza. La `PUT` richiesta restituisce un token di sessione che deve essere incluso nelle `GET` richieste successive al servizio di metadati dell'istanza. Il token di sessione che definisce la durata della sessione. La durata della sessione può essere compresa tra un minimo di un secondo e un massimo di sei ore. Durante questa durata, puoi utilizzare lo stesso token di sessione per le richieste successive. Dopo la scadenza di questa durata, è necessario creare un nuovo token di sessione per le richieste future. Il token è necessario per accedere ai metadati utilizzando. IMDSv2

1. Includi il token in tutte le richieste `GET` al servizio di metadati dell'istanza.

   1. Il token è una chiave specifica dell'istanza. Il token non è valido su altre istanze EC2 compatibili e verrà rifiutato se si tenta di utilizzarlo al di fuori dell'istanza su cui è stato generato.

   1. La richiesta `PUT` deve includere un'intestazione che specifica il Time To Live (TTL) per il token, in secondi, fino a un massimo di sei ore (21.600 secondi). Il token rappresenta una sessione logica. Il TTL specifica la durata di validità del token e, pertanto, la durata della sessione.

   1. Dopo che un token scade, per continuare ad accedere ai metadati dell'istanza, devi creare una nuova sessione utilizzando un'altra richiesta `PUT`.

   1. Puoi scegliere di riutilizzare un token o creare un nuovo token con ogni richiesta. Per un piccolo numero di richieste, potrebbe essere più semplice generare e utilizzare immediatamente un token ogni volta che occorre accedere al servizio di metadati dell'istanza. Per maggior efficienza, tuttavia, puoi specificare una durata maggiore per il token e riutilizzarlo, piuttosto che dover riscrivere una richiesta `PUT` ogni volta che devi richiedere metadati dell'istanza. Non esiste un limite effettivo al numero di token simultanei, ciascuno dei quali rappresenta la propria sessione.

HTTP `GET` e `HEAD` metodi sono consentiti nelle richieste di metadati delle IMDSv2 istanze. `PUT`le richieste vengono rifiutate se contengono un'`X-Forwarded-For`intestazione.

Per impostazione predefinita, la risposta alle `PUT` richieste ha un limite di risposta (time to live) di 1 a livello di protocollo IP. IMDS for Snow non è in grado di modificare il limite di hop per le `PUT` risposte.

L'esempio seguente utilizza uno script di shell Linux e IMDSv2 recupera gli elementi di metadati dell'istanza di primo livello. Questo esempio:

1. Crea un token di sessione della durata di sei ore (21.600 secondi) utilizzando la `PUT` richiesta.

1. Memorizza l'intestazione del token di sessione in una variabile denominata. `TOKEN`

1. Richiede gli elementi di metadati di primo livello utilizzando il token.

Usa due comandi per generare il EC2 token compatibile. È possibile eseguire i comandi separatamente o come un unico comando.

Innanzitutto, generare un token utilizzando il comando riportato di seguito.

**Nota**  
`X-aws-ec2-metadata-token-ttl-seconds`è un'intestazione obbligatoria. Se questa intestazione non è inclusa, riceverai un codice di errore **400 - Parametri mancanti o non validi**.

```
    [ec2-user ~]$ TOKEN=curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"
```

Quindi, utilizzate il token per generare elementi di metadati di primo livello utilizzando il seguente comando.

```
    [ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/
```

**Nota**  
Se si verifica un errore nella creazione del token, nella variabile viene memorizzato un messaggio di errore anziché un token valido e il comando non funzionerà.

È possibile memorizzare il token e combinare i comandi. L'esempio seguente combina i due comandi precedenti e memorizza l'intestazione del token di sessione in una variabile denominata`TOKEN`.

**Example di comandi combinati**  

```
    [ec2-user ~]$ TOKEN=curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" \
    && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/
```

Dopo aver creato un token, puoi riutilizzarlo finché non scade. Il comando di esempio seguente ottiene l'ID dell'AMI utilizzato per avviare l'istanza e lo memorizza nell'ID `$TOKEN` creato nell'esempio precedente.

**Example di riutilizzare un token**  

```
    [ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ami-id                        
```

## IMDSv1 su uno Snowball Edge
<a name="imdsv1"></a>

IMDSv1 utilizza il modello di richiesta-risposta. Per richiedere i metadati dell'istanza, invii una `GET` richiesta al servizio di metadati dell'istanza.

```
    [ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/                   
```

I metadati dell'istanza sono disponibili dall'istanza in esecuzione, quindi non è necessario utilizzare la EC2 AWS CLI console Amazon o accedervi. Ciò può risultare utile quando sta scrivendo script da eseguire dall'istanza. Ad esempio, puoi accedere all'indirizzo IP locale dell'istanza dai metadati dell'istanza per gestire una connessione a un'applicazione esterna. I metadati dell'istanza sono suddivisi in categorie. Per una descrizione di ciascuna categoria di metadati di istanza, consulta [Metadati delle istanze supportate e dati utente](https://docs.aws.amazon.com/snowball/latest/developer-guide/edge-compute-instance-metadata.html) in questa guida. 

Per visualizzare tutte le categorie di metadati di istanza dall'interno di un'istanza in esecuzione, utilizza il seguente URI: IPv4 

```
    http://169.254.169.254/latest/meta-data/
```

Gli indirizzi IP sono indirizzi link-local e sono validi solo dall'istanza. Per ulteriori informazioni, consultare [Indirizzo link-local](https://en.wikipedia.org/wiki/Link-local_address) su Wikipedia.

Tutti i metadati dell'istanza vengono restituiti come testo (tipo di contenuto HTTP `text/plain`).

Una richiesta per una specifica risorsa di metadati restituisce il valore appropriato o un codice di errore HTTP **404 - Not Found**, se la risorsa non è disponibile.

Una richiesta per una risorsa di metadati generale (quando l'URI termina con un `/` carattere) restituisce un elenco di risorse disponibili o un codice di errore HTTP **404 - Not Found** se tale risorsa non esiste. Gli elementi dell'elenco si trovano su righe separate, terminate da feed di riga (codice di caratteri ASCII 10).

Per le richieste effettuate utilizzando IMDSv1, è possibile restituire i seguenti codici di errore HTTP:
+ **400 ‐ Parametri mancanti o non validi**: la `PUT` richiesta non è valida.
+ **401 ‐ Non autorizzato**: la `GET` richiesta utilizza un token non valido. L'operazione consigliata è quella di generare un nuovo token.
+ **403 ‐ Proibita**: la richiesta non è consentita o il servizio di metadati dell'istanza è disattivato.