Usar IMDSv2 - Amazon Elastic Compute Cloud

Usar IMDSv2

É possível acessar metadados de instância em uma instância em execução usando um dos seguintes métodos:

  • Serviço de metadados da instância versão 1 (IMDSv1) – um método de solicitação/resposta

  • Serviço de metadados da instância versão 2 (IMDSv2) – um método orientado a sessões

  • Para usar o EC2Launch com IMDSv2, a versão deve ser a 1.3.2002730 ou posterior.

Por padrão, você pode usar o IMDSv1 ou o IMDSv2 ou ambos. O serviço de metadados da instância faz distinção entre as solicitações do IMDSv1 e do IMDSv2 com base na presença dos cabeçalhos PUT ou GET , que são exclusivos do IMDSv2, nessa solicitação. Para obter mais informações, consulte Adicionar defesa profunda contra firewalls abertos, proxies reversos e vulnerabilidades SSRF com melhorias no serviço de metadados da instância do EC2.

Você pode configurar o serviço de metadados da instância em cada instância de forma que o código ou os usuários locais usem o IMDSv2. Quando você especifica que o IMDSv2 deve ser usado, o IMDSv1 não funciona mais. Para mais informações, consulte Configurar as opções de metadados da instância.

Para recuperar metadados da instância, consulte Recuperar metadados da instância.

nota

Os exemplos nesta seção usam o endereço IPv4 do serviço de metadados da instância: 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 serviço de metadados da instância é compatível com comandos IMDSv2. O endereço IPv6 só é acessível no Instâncias criadas no Sistema Nitro.

Como Serviço de metadados da instância versão 2 funciona

O IMDSv2 usa solicitações orientadas a sessão. Com solicitações orientadas a sessão, você cria um token de sessão que define a duração da sessão, que pode ser, no mínimo, um segundo e, no máximo, seis horas. Durante o período especificado, você pode usar o mesmo token de sessão para solicitações subsequentes. Depois que a duração especificada expira, você deve criar um novo token de sessão para uso em solicitações futuras.

O exemplo a seguir usa um script shell do Linux e o IMDSv2 para recuperar os itens de metadados de nível superior de instância. O exemplo:

  • Cria um token de sessão que dura seis horas (21.600 segundos) usando a solicitação PUT.

  • Armazena o cabeçalho do token da sessão em uma variável chamada TOKEN

  • Solicita os itens de metadados de nível superior usando o token

Você pode executar dois comandos separados ou combiná-los.

Comandos separados

Primeiro, gere um token usando o comando a seguir.

[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/

Comandos combinados

Você pode 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.

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á.

[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, você pode 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.

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

Quando você usa o IMDSv2 para solicitar os metadados da instância, a solicitação deve incluir o seguinte:

  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 retorna um token que deve ser incluído em solicitações GET subsequentes para o serviço de metadados da instância. O token é exigido para acessar metadados usando o IMDSv2.

  2. Inclua o token em todas as solicitações GET para o serviço de metadados da instância. Quando o uso do token está definido como required, as solicitações sem um token válido ou com um token expirado recebem um código de erro HTTP 401 - Unauthorized. Para obter informações sobre como alterar o requisito de uso do token, consulte modify-instance-metadata-options na Referência de comandos da AWS CLI.

    • O token é uma chave específica da instância. O token não é válido em outras instâncias do EC2 e será rejeitado se você tentar usá-lo fora da instância na qual foi gerado.

    • 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.

    • Depois que o token expira, para continuar a acessar os metadados da instância, você deve criar uma nova sessão usando outro PUT.

    • É 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, você pode 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. No entanto, o IMDSv2 ainda é restringido pela conexão do serviço de metadados da instância e pelos limites de controle de utilização. Para mais informações, consulte Limitação de consulta.

Os métodos HTTP GET e HEAD são permitidos em solicitações de metadados de instâncias do IMDSv2. As solicitações PUT serão rejeitadas se contiverem um cabeçalho X-Forwarded-For.

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. É possível ajustar o limite de saltos usando o comando modify-instance-metadata-options se você precisar de um limite maior. Por exemplo, um limite de saltos maior pode ser necessário para compatibilidade com versões anteriores de serviços de contêiner em execução na instância. Para obter mais informações, consulte modify-instance-metadata-options na Referência de comandos da AWS CLI.

Transição para usar o Serviço de metadados da instância versão 2

O uso do Serviço de metadados de instância versão 2 (IMDSv2) é opcional. O Serviço de metadados de instância versão 1 (IMDSv1) continuará a ter suporte indefinidamente. Se você optar por migrar usando o IMDSv2, recomendamos usar as ferramentas e o caminho de transição a seguir.

Ferramentas para ajudar com a transição para o IMDSv2

Se seu software usar o IMDSv1, use as ferramentas a seguir para ajudar a configurar o software para usar o IMDSv2.

  • Software da AWS: as versões mais recentes dos AWS SDKs e CLIs oferecem suporte ao IMDSv2. Para usar o IMDSv2, verifique se as instâncias do EC2 têm as versões mais recentes dos SDKs e CLIs da AWS. Para obter informações sobre como atualizar a CLI, consulte Instalação, atualização e desinstalação da AWS CLI no Guia do usuário da AWS Command Line Interface.

    Todos os pacotes de software Amazon Linux 2 suportam IMDSv2.

  • CloudWatch: o IMDSv2 usa sessões com token, enquanto o IMDSv1 não. A métrica MetadataNoToken do CloudWatch rastreia o número de chamadas para o serviço de metadados da instância que estão usando o IMDSv1. Rastreando essa métrica até zero, você pode determinar se e quando todo o software foi atualizado para usar o IMDSv2. Para mais informações, consulte Métricas de instância.

  • Atualizações das CLIs e APIs do EC2: para instâncias existentes, é possível usar o comando modify-instance-metadata-options da CLI (ou a API ModifyInstanceMetadataOptions) para exigir o uso do IMDSv2. Para novas instâncias, é possível usar o comando run-instances da CLI (ou a API RunInstances) e o parâmetro metadata-options para executar novas instâncias que exigem o uso do IMDSv2.

    Para exigir o uso do IMDSv2 em todas as novas instâncias executadas por grupos de Auto Scaling, seus grupos de Auto Scaling podem usar um modelo de execução ou uma configuração de execução. Quando você cria um modelo de execução ou cria uma configuração de execução, você deve configurar os parâmetros de MetadataOptions para exigir o uso do IMDSv2. Depois que você configura o modelo de execução ou a configuração de execução, o grupo de Auto Scaling executa novas instâncias usando o novo modelo de execução ou configuração de execução, mas as instâncias existentes não são afetadas.

    Use o comando modify-instance-metadata-options da CLI (ou a API ModifyInstanceMetadataOptions) para exigir o uso do IMDSv2 em instâncias existentes, ou encerre as instâncias e o grupo de Auto Scaling executará novas instâncias de substituição com as configurações das opções de metadados de instância definidas no modelo ou na configuração de execução.

  • Políticas do IAM e SCPs: é possível usar uma condição do IAM para exigir que os usuários do IAM não executem uma instância a menos que ela use IMDSv2. Também é possível usar condições do IAM para exigir que os usuários do IAM não podem executar instâncias para habilitar novamente o IMDSv1 e exigir que o serviço de metadados da instância esteja disponível na instância.

    É possível usar as chaves de condição ec2:MetadataHttpTokens, ec2:MetadataHttpPutResponseHopLimit e ec2:MetadataHttpEndpoint do IAM para controlar o uso de RunInstances e da API ModifyInstanceMetadataOptions e da CLI correspondente. Se uma política for criada, e um parâmetro na chamada à API não corresponder ao estado especificado na política usando a chave de condição, a chamada à API ou à CLI falhará com uma resposta UnauthorizedOperation. Essas chaves de condição podem ser usadas em políticas do IAM ou políticas de controle de serviço (SCPs) do AWS Organizations.

    Além disso, é possível escolher uma camada adicional de proteção para exigir a alteração do IMDSv1 para o IMDSv2. Na camada de gerenciamento de acesso com relação às APIs chamadas por meio de credenciais de função do EC2, você pode usar uma nova chave de condição nas políticas do IAM ou nas políticas de controle de serviço (SCPs) do AWS Organizations. Especificamente, ao usar a chave da condição da política ec2:RoleDelivery com um valor de 2.0 nas políticas do IAM, as chamadas à API feitas com credencias de função do EC2 obtidas do IMDSv1 receberão uma resposta UnauthorizedOperation. A mesma coisa pode ser obtida de forma mais ampla com essa condição exigida por uma SCP. Isso garante que as credenciadas entregues por meio do IMDSv1 não podem ser realmente usadas para chamar APIs porque todas as chamadas à API que não corresponderem à condição especificada receberão um erro UnauthorizedOperation. Para obter exemplos de políticas do IAM, consulte Trabalhar com metadados de instância. Para obter mais informações, consulte Políticas de controle de serviço no Guia do usuário do AWS Organizations.

Caminho recomendado para exigir acesso ao IMDSv2

Usando as ferramentas acima, recomendamos que você siga este caminho para fazer a transição para o IMDSv2:

Etapa 1: No início

Atualize os SDKs, as CLIs e o software que usam credenciais de função em suas instâncias do EC2 para versões compatíveis com o IMDSv2. Para obter informações sobre como atualizar a CLI, consulte Atualização para a versão mais recente da AWS CLI no Guia do usuário da AWS Command Line Interface.

Depois, altere o software que acessa os metadados da instância diretamente (ou seja, que não usa um SDK) usando as solicitações do IMDSv2.

Etapa 2: Durante a transição

Acompanhe o andamento da transição usando a métrica do CloudWatch MetadataNoToken. Essa métrica mostra o número de chamadas para o serviço de metadados da instância que estão usando o IMDSv1 em suas instâncias. Para mais informações, consulte Métricas de instância.

Etapa 3: Quando tudo estiver pronto em todas as instâncias

Tudo estará pronto em todas as instâncias quando a métrica do CloudWatch MetadataNoToken registrar uso zero do IMDSv1. Nessa fase, é possível fazer o seguinte:

  • Nessa fase, você pode exigir o uso do IMDSv2 por meio do comando modify-instance-metadata-options. É possível fazer essas alterações em instâncias em execução. Não é necessário reiniciar as instâncias.

  • Para novas instâncias: ao executar uma nova instância, é possível seguir um destes procedimentos:

    • No assistente de instância de execução do console do Amazon EC2, defina Metadata accessible (Metadados acessíveis) como Enabled (Habilitado) e Metadata version (Versão de metadados) como V2. Para mais informações, consulte Etapa 3: configurar detalhes da instância.

    • Use o comando run-instances para especificar que apenas o IMDSv2 deve ser usado.

A atualização de opções de metadados de instâncias existentes está disponível apenas por meio da API ou AWS CLI. No momento, não está disponível no console do Amazon EC2. Para mais informações, consulte Configurar as opções de metadados da instância.

Etapa 4: Quando todas as suas instâncias tiverem feito a transição para o IMDSv2

É possível usar as chaves de condição ec2:MetadataHttpTokens, ec2:MetadataHttpPutResponseHopLimit e ec2:MetadataHttpEndpoint do IAM para controlar o uso de RunInstances e da API ModifyInstanceMetadataOptions e da CLI correspondente. Se uma política for criada, e um parâmetro na chamada à API não corresponder ao estado especificado na política usando a chave de condição, a chamada à API ou à CLI falhará com uma resposta UnauthorizedOperation. Para obter exemplos de políticas do IAM, consulte Trabalhar com metadados de instância.