Recuperar metadados da instância
Como os metadados da instância estão disponíveis na sua instância em execução, você não precisa usar o console do Amazon EC2 nem a AWS CLI. 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 Categorias de metadados da instância
Para visualizar todas as categorias de metadados da instância dentro de uma instância em execução, use o seguinte URI de IPv4 ou IPv6:
IPv4
http://169.254.169.254/latest/meta-data/IPv6
http://[fd00:ec2::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ços locais de link neste guia do usuário e Endereço de enlace local
nota
Os exemplos nesta seção usam o endereço IPv4 do IMDS: 169.254.169.254. Se você estiver recuperando metadados de instância para instâncias do EC2 pelo endereço IPv6, certifique-se de habilitar e usar o endereço IPv6: [fd00:ec2::254]. O endereço IPv6 do IMDS é compatível com comandos IMDSv2. O endereço IPv6 pode ser acessado somente em instâncias desenvolvidas no AWS Nitro System.
O formato do comando é diferente dependendo de se IMDSv1 ou IMDSv2 é usado. Por padrão, é possível usar as duas versões do IMDS. Para exigir o uso do IMDSv2, consulte Usar IMDSv2.
É possível usar uma ferramenta, como cURL, conforme mostrado no exemplo a seguir.
Para que o comando recupere metadados da instância de uma instância do Windows, consulte Recuperar metadados da instância no Guia do usuário do Amazon EC2 para instâncias do Windows.
Custos
Você não será cobrado pelas solicitações HTTP usadas para recuperar os metadados da instância e os dados do usuário.
Considerações
Para evitar problemas com a recuperação de metadados de instância, considere o seguinte:
-
Em um ambiente de contêiner, recomendamos definir o limite de saltos como 2.
Os SDKs da AWS usam chamadas IMDSv2 por padrão. Se a chamada IMDSv2 não receber resposta, o SDK tenta novamente o atendimento e, se houver falha, usa IMDSv1. Isso pode resultar em um atraso, especialmente em um ambiente de contêiner. Em um ambiente de contêiner, se o limite de salto for 1, a resposta de IMDSv2 não retorna porque ir ao contêiner é considerado um salto de rede adicional. Para evitar o processo de recuar para IMDSv1 e o atraso resultante, em um ambiente de contêiner recomendamos que você defina o limite de salto como 2. Para ter mais informações, consulte Configurar as opções de metadados da instância.
-
Para IMDSv2, use
/latest/api/tokenao recuperar o token.Emitir solicitações
PUTpara qualquer caminho específico da versão, por exemplo/2021-03-23/api/token, fará com que o serviço de metadados retorne erros 403 Forbidden. Este é o comportamento pretendido. -
Se o IMDSv2 for necessário, o IMDSv1 não funcionará.
Você pode verificar se o IMDSv2 é necessário para uma instância, da seguinte forma: Selecione a instância para ver seus detalhes e verifique o valor deIMDSv2. O valor éObrigatório(somente IMDSv2 pode ser usado) ouOpcional(IMDSv2 e IMDSv1 podem ser usados).
Respostas e mensagens de erro
Todos os metadados de instância são retornados como texto (tipo de conteúdo HTTP text/plain).
Uma solicitação para um recurso de metadados específico retorna o valor apropriado, ou um código de erro de HTTP 404 - Not Found se o recurso não estiver disponível.
Uma solicitação de um recurso de metadados geral (o URI termina com /) retorna uma lista de recursos disponíveis, ou um código de erro de HTTP 404 - Not Found se não houver esse recurso. 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 o Serviço de metadados da instância versão 2, os seguintes códigos de erro HTTP podem ser retornados:
-
400 - Missing or Invalid Parameters– a solicitaçãoPUTnão é válida. -
401 - Unauthorized– a solicitaçãoGETusa um token inválido. A ação recomendada é gerar um novo token. -
403 - Forbidden: a solicitação não é permitida ou o IMDS está desativado.
Exemplos de recuperação de metadados da instância
Os exemplos a seguir fornecem comandos que é possível usar em uma instância do Linux. Para obter os comandos para recuperar metadados da instância de uma instância do Windows, consulte Recuperar metadados da instância no Guia do usuário do Amazon EC2 para instâncias do Windows.
Exemplos
- Obter as versões disponíveis dos metadados da instância
- Obter itens de metadados de nível superior.
- Obter a lista de chaves públicas disponíveis
- Mostrar os formatos nos quais a chave pública 0 está disponível
- Obter a chave pública 0 (no formato de chave OpenSSH)
- Obter o ID de sub-rede de uma instância
- Obter as tags de instância de uma instância de uma instância
Obter as versões disponíveis dos metadados da instância
Este exemplo obtém as versões disponíveis dos metadados da instância. Cada versão indica uma compilação de metadados de instância quando novas categorias de metadados de instância foram lançadas. As versões de compilação de metadados de instância não têm correlação com as versões de API do Amazon EC2. As versões anteriores estarão disponíveis caso você tenha scripts que contam com a estrutura e as informações presentes em uma versão anterior.
nota
Para evitar ter que atualizar seu código sempre que o Amazon EC2 lançar uma nova compilação de metadados de instância, recomendamos que você use latest no caminho em vez do número da versão. Por exemplo, use latest da seguinte maneira:
curl http://169.254.169.254/latest/meta-data/ami-id
Obter itens de metadados de nível superior.
Este exemplo obtém itens de metadados de nível superior. Para ter mais informações, consulte Categorias de metadados da instância.
Os exemplos a seguir obtêm os valores de alguns dos itens de metadados de nível superior que foram obtidos no exemplo anterior. As solicitações do IMDSv2 usam o token armazenado que foi criado no comando do exemplo anterior, supondo-se que ele não expirou.
Obter a lista de chaves públicas disponíveis
Este exemplo obtém uma lista de chaves públicas disponíveis.
Mostrar os formatos nos quais a chave pública 0 está disponível
Este exemplo mostra os formatos nos quais a chave pública 0 está disponível.
Obter a chave pública 0 (no formato de chave OpenSSH)
Este exemplo obtém a chave pública 0 (no formato de chave OpenSSH).
Obter o ID de sub-rede de uma instância
Este exemplo obtém o ID de sub-rede para uma instância.
Obter as tags de instância de uma instância de uma instância
Nos exemplos a seguir, a instância de exemplo tem tags em metadados de instância habilitadas e as tags de instância Name=MyInstance e Environment=Dev.
Este exemplo obtém todas as chaves de tag de instância de uma instância.
O exemplo a seguir obtém o valor da chave Name que foi obtida no exemplo anterior. A solicitação de IMDSv2 usa o token armazenado que foi criado no comando do exemplo anterior, supondo que ele não tenha expirado.
Limitação de consulta
Controlamos a utilização de consultas ao IMDS em uma base por instância, e limitamos o número de conexões simultâneas de uma instância com o IMDS.
Se você estiver usando o IMDS para recuperar as credenciais de segurança da AWS, evite consultar as credenciais durante cada transação ou simultaneamente em um número elevado de threads ou processos, pois isso pode levar a uma limitação. Em vez disso, recomendamos que você armazene em cache as credenciais até elas começarem a se aproximar da data de expiração. Para obter mais informações sobre o perfil do IAM e as credenciais de segurança associadas ao perfil, consulte Recuperar credenciais de segurança dos metadados da instância.
Se você ficar limitado ao acessar o IMDS, tente a consulta novamente com uma estratégia de recuo exponencial.
Limite de acesso ao IMDS
É possível considerar o uso de regras do firewall local para desabilitar o acesso de alguns ou de todos os processos para o IMDS.
nota
Para instâncias desenvolvidas no AWS Nitro System, o IMDS pode ser acessado usando a própria rede quando um dispositivo de rede na VPC, como um roteador virtual, encaminha pacotes para o endereço do IMDS e a verificação de origem e de destino padrão na instância está desabilitada. Para evitar que uma fonte externa à sua VPC acesse o IMDS, recomendamos modificar a configuração do dispositivo de rede para descartar pacotes com o endereço IPv4 de destino do IMDS 169.254.169.254 e, se você tiver habilitado o endpoint IPv6, o endereço IPv6 do IMDS [fd00:ec2::254].
Usar iptables para limitar o acesso
O exemplo a seguir usa iptables do Linux e seu módulo owner para impedir que o servidor Web do Apache (com base no ID de usuário da instalação padrão do apache) acesse 169.254.169.254. Ele usa uma regra de negação para rejeitar todas as solicitações de metadados de instância (IMDSv1 ou IMDSv2) de qualquer processo que execute como esse usuário.
$sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner --uid-owner apache --jump REJECT
Ou é possível considerar permitir o acesso apenas a usuários ou grupos específicos usando regras de permissão. As regras de permissão podem ser mais fáceis de gerenciar de uma perspectiva de segurança, porque elas exigem que você decida qual software precisa acessar os metadados de instância. Se você usar regras de permissão, haverá menos probabilidade de você permitir acidentalmente que o software acesse o serviço de metadados (que você não queria que tivesse acesso) se você alterar o software ou a configuração posteriormente em uma instância. Também é possível combinar o uso de grupos com regras de permissão, para que você possa adicionar ou remover usuários de um grupo com permissão sem precisar alterar a regra do firewall.
O exemplo a seguir impede o acesso ao IMDS por todos os processos, exceto os processos em execução na conta do usuário trustworthy-user.
$sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner ! --uid-ownertrustworthy-user--jump REJECT
nota
-
Para usar regras de firewall local, você precisa adaptar os comandos do exemplo anterior para se ajustarem a suas necessidades.
-
Por padrão, as regras de iptables não são persistentes em todas as reinicializações do sistema. Elas podem ser transformadas em persistentes usando recursos do SO não descritos aqui.
-
O módulo
ownerdas iptables só corresponderá à associação do grupo se o grupo for o grupo primário de um determinado usuário local. Outros grupos não são correspondidos.
Usar PF ou IPFW para limitar o acesso
Se você estiver usando FreeBSD ou OpenBSD, poderá considerar também o uso de PF ou IPFW. Os exemplos a seguir limitam o acesso ao IMDS apenas ao usuário raiz.
PF
$block out inet proto tcp from any to 169.254.169.254
$pass out inet proto tcp from any to 169.254.169.254 user root
IPFW
$allow tcp from any to 169.254.169.254 uid root
$deny tcp from any to 169.254.169.254
nota
A ordem dos comandos PF e IPFW é importante. O padrão de PF e a regra correspondente mais recente, e o padrão de IPFW é a primeira regra correspondente.
