As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Versões do IMDS em um Snowball Edge
É possível acessar metadados de instância em uma instância em execução usando o IMDS versão 2 ou o IMDS versão 1:
+ Instance Metadata Service versão 2 (IMDSv2), um método orientado a sessões
+ Instance Metadata Service versão 1 (IMDSv1), um método de solicitação-resposta
Dependendo da versão do seu software Snow, você pode usar IMDSv1 IMDSv2, ou ambos. Isso também depende do tipo de AMI em execução na instância EC2 compatível. Alguns AMIs, como aqueles que executam o Ubuntu 20.04, exigem IMDSv2. O serviço de metadados da instância distingue IMDSv1 e IMDSv2 solicita com base na presença de cabeçalhos `PUT` ou `GET` cabeçalhos. IMDSv2usa esses dois cabeçalhos. IMDSv1 usa somente o `GET` cabeçalho.
AWS incentiva o uso de, IMDSv2 em vez de IMDSv1 porque IMDSv2 inclui maior segurança. Para obter mais informações, consulte [Adicionar defesa aprofundada contra firewalls abertos, proxies reversos e vulnerabilidades de SSRF com aprimoramentos](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/) no Instance Metadata Service. EC2
## IMDSv2 em um Snowball Edge
Quando você usa IMDSv2 para solicitar metadados da instância, a solicitação precisa seguir estas regras:
1. Use uma solicitação `PUT` para solicitar a inicialização de uma sessão para o serviço de metadados da instância. A solicitação `PUT` exibe um token de sessão que deve ser incluído em solicitações `GET` subsequentes para o serviço de metadados da instância. O token de sessão que define a duração da sessão. A duração da sessão pode variar de um segundo, no mínimo, a seis horas, no máximo. Durante o período especificado, é possível usar o mesmo token de sessão para solicitações subsequentes. Depois que a duração especificada expira, crie um novo token de sessão para uso em solicitações futuras. O token é necessário para acessar os metadados usando IMDSv2.
1. Inclua o token em todas as solicitações `GET` para o serviço de metadados da instância.
1. O token é uma chave específica da instância. O token não é válido em outras instâncias EC2 compatíveis e será rejeitado se você tentar usá-lo fora da instância na qual ele foi gerado.
1. A solicitação `PUT` deve incluir um cabeçalho que especifique a vida útil (TTL) do token, em segundos, até um máximo de seis horas (21.600 segundos). O token representa uma sessão lógica. O TTL especifica o período de validade do token e, portanto, a duração da sessão.
1. Depois que o token expira, para continuar a acessar os metadados da instância, crie uma nova sessão usando outra solicitação `PUT`.
1. É possível optar por reutilizar um token ou criar um novo token para cada solicitação. Para um número pequeno de solicitações, pode ser mais fácil gerar e usar imediatamente um token a cada vez que você precisar acessar o serviço de metadados da instância. Mas, para obter eficiência, é possível especificar uma duração maior para o token e reutilizá-lo, em vez de precisar escrever uma solicitação `PUT` toda vez que precisar solicitar metadados da instância. Não há um limite prático para o número de tokens simultâneos, cada um representando sua própria sessão.
HTTP `GET` e `HEAD` métodos são permitidos em solicitações de metadados de IMDSv2 instância. `PUT`as solicitações são rejeitadas se contiverem um `X-Forwarded-For` cabeçalho.
Por padrão, a resposta a solicitações `PUT` tem um limite de saltos de resposta (vida útil) de 1 no nível de protocolo IP. O IMDS for Snow não tem a capacidade de modificar o limite de salto nas respostas `PUT`.
O exemplo a seguir usa um script de shell do Linux IMDSv2 para recuperar os itens de metadados da instância de nível superior. Esse exemplo:
1. Cria um token de sessão que dura seis horas (21.600 segundos) usando a solicitação `PUT`.
1. Armazena o cabeçalho do token da sessão em uma variável chamada `TOKEN`.
1. Solicita os itens de metadados de nível superior usando o token.
Use dois comandos para gerar o token EC2 compatível. É possível executar os comandos separadamente ou como um único comando.
Primeiro, gere um token usando o comando a seguir.
**nota**
`X-aws-ec2-metadata-token-ttl-seconds` é um cabeçalho obrigatório. Se esse cabeçalho não for incluído, você receberá um código de erro **400 - Parâmetros ausentes ou inválidos**.
```
[ec2-user ~]$ TOKEN=curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"
```
Em seguida, use o token para gerar itens de metadados de nível superior usando o comando a seguir.
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/
```
**nota**
Se houver um erro na criação do token, em vez de um token válido, uma mensagem de erro será armazenada na variável e o comando não funcionará.
É possível armazenar o token e combinar os comandos. O exemplo a seguir combina os dois comandos acima e armazena o cabeçalho do token de sessão em uma variável chamada `TOKEN`.
**Example de comandos combinados**
```
[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/
```
Depois de criar um token, é possível reutilizá-lo até que ele expire. No comando de exemplo a seguir, que obtém o ID da AMI usada para executar a instância, o token armazenado em `$TOKEN` no exemplo anterior é reutilizado.
**Example de reutilizar um token**
```
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ami-id
```
## IMDSv1 em um Snowball Edge
IMDSv1 usa o modelo de solicitação-resposta. Para solicitar metadados da instância, envie uma solicitação `GET` para o serviço de metadados da instância.
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/
```
Os metadados da sua instância estão disponíveis na sua instância em execução, então você não precisa usar o EC2 console da Amazon ou o AWS CLI para acessá-los. Isso pode ser útil quando você for elaborar scripts a serem executados a partir de sua instância. Por exemplo, é possível acessar o endereço IP local de sua instância a partir dos metadados da instância para gerenciar uma conexão com uma aplicação externa. Os metadados da instância são divididos em categorias. Para obter uma descrição de cada categoria de metadados de instância, consulte [metadados de instância compatíveis e dados do usuário](https://docs.aws.amazon.com/snowball/latest/developer-guide/edge-compute-instance-metadata.html) neste guia.
Para visualizar todas as categorias de metadados da instância de dentro de uma instância em execução, use o seguinte IPv4 URI:
```
http://169.254.169.254/latest/meta-data/
```
Os endereços IP são endereços locais de link e são válidos apenas a partir da instância. Para obter mais informações, consulte [Endereço de link local](https://en.wikipedia.org/wiki/Link-local_address) na Wikipedia.
Todos os metadados de instância são retornados como texto (tipo de conteúdo HTTP `text/plain`).
Uma solicitação para um atributo de metadados específico retorna o valor apropriado, ou um código de erro de HTTP **404 - Not Found** se o atributo não estiver disponível.
Uma solicitação de um recurso de metadados geral (o URI termina com `/`) retorna uma lista de atributos disponíveis, ou um código de erro de HTTP **404 - Not Found** se não houver esse atributo. Os itens da lista estão em linhas separadas que são delimitadas por caracteres de alimentação de linha (ASCII 10).
Para solicitações feitas usando IMDSv1, os seguintes códigos de erro HTTP podem ser retornados:
+ **400 ‐ parâmetros ausentes ou inválidos**: a solicitação `PUT` não é válida.
+ **401 ‐ não autorizado**: a solicitação `GET` usa um token inválido. A ação recomendada é gerar um novo token.
+ **403 ‐ proibido**: a solicitação não é permitida ou o serviço de metadados de instância está desativado.