Recuperar metadatos de instancia
Puesto que los metadatos de la instancia se encuentran disponibles en la instancia en ejecución, no se necesita utilizar la consola de Amazon EC2 ni la AWS CLI. Esto puede resultar de utilidad al escribir scripts para ejecutarlos desde la instancia. Por ejemplo, puede obtener acceso a la dirección IP local de la instancia desde los metadatos de la instancia para administrar una conexión a una aplicación externa.
Los metadatos de instancia se dividen en categorías. Para obtener una descripción de cada categoría de metadatos de instancia, consulte Categorías de metadatos de instancia.
Para ver todas las categorías de metadatos de instancia dentro de una instancia en ejecución, utilice las siguientes URI IPv4 o IPv6.
IPv4
http://169.254.169.254/latest/meta-data/
IPv6
http://[fd00:ec2::254]/latest/meta-data/
Las direcciones IP son direcciones de enlace local y solo son válidas desde la instancia. Para obtener más información, consulte Direcciones de enlace local en esta guía de usuario y en Link-local address
nota
En los ejemplos de esta sección, se utiliza la dirección IPv4 de IMDS: 169.254.169.254
. Si recupera metadatos de instancia para las instancias EC2 a través de la dirección IPv6, asegúrese de habilitar y utilizar la dirección IPv6 en su lugar: [fd00:ec2::254]
. La dirección IPv6 de IMDS es compatible con los comandos de IMDSv2. Solo se puede acceder a la dirección IPv6 en instancias integradas en el AWS Nitro System.
El formato de comando difiere en función de si usa IMDSv1 o IMDSv2. De forma predeterminada, puede usar ambas versiones de IMDS. Para exigir el uso de IMDSv2, consulte Utilizar IMDSv2.
Puede utilizar cmdlets de PowerShell para recuperar el URI. Por ejemplo, si ejecuta la versión 3.0 o posterior de PowerShell, debe utilizar el siguiente cmdlet.
Si no quiere utilizar PowerShell, puede instalar una herramienta de terceros como GNU Wget o cURL.
importante
Si instala una herramienta de terceros en una instancia de Windows, asegúrese de leer detenidamente la documentación asociada, ya que el método para llamar al HTTP y el formato de salida pueden ser distintos a lo que se indica aquí.
Para obtener el comando que permite recuperar los metadatos de la instancia de una instancia de Linux, consulte Recuperar metadatos de instancia en la Guía del usuario de Amazon EC2 para instancias de Windows.
Costos
No se le cobrará por las solicitudes HTTP utilizadas para recuperar metadatos de instancia y datos de usuario.
Consideraciones
Para evitar problemas con la recuperación de metadatos de instancia, tenga en cuenta lo siguiente:
-
En un entorno de contenedores, recomendamos establecer el límite de saltos en 2.
Los AWS SDK utilizan llamadas a IMDSv2 de forma predeterminada. Si la IMDSv2 llamada no recibe respuesta, el SDK reintenta la llamada y, si aún no tiene éxito, utiliza IMDSv1. Esto puede generar un retraso, especialmente en un entorno de contenedor. En un entorno de contenedor, si el límite de saltos es 1, no devuelve la IMDSv2 respuesta porque ir al contenedor se considera un salto de red adicional. Para evitar el proceso de retroceso IMDSv1 y el retraso resultante, en un entorno de contenedor recomendamos que establezca el límite de saltos en 2. Para obtener más información, consulte Configurar las opciones de metadatos de instancia.
-
Creación de AMI de Windows personalizadas con Sysprep.
Si inicia una instancia de Windows con una AMI de Windows personalizada, para asegurarse de que el IMDS funcione en la instancia, la AMI debe ser una imagen estandarizada creada con Sysprep. De lo contrario, IMDS no funcionará.
-
En el caso de IMDSv2, debe utilizar
/latest/api/token
al recuperar el token.La emisión de solicitudes
PUT
a cualquier ruta específica de la versión, como, por ejemplo,/2021-03-23/api/token
, dará lugar a que el servicio de metadatos devuelva errores 403 Forbidden (403 Prohibido). Este es el comportamiento deseado. -
Si se requiere IMDSv2, IMDSv1 no funciona.
Puede comprobar si se requiere IMDSv2 para una instancia de la siguiente manera: seleccione la instancia para ver sus detalles y compruebe el valor de IMDSv2. El valor es Obligatorio (solo se puede usar IMDSv2) u Opcional (se pueden utilizar IMDSv2 e IMDSv1).
Respuestas y mensajes de error
Todos los metadatos de instancia se devuelven como texto (tipo de contenido HTTP text/plain
).
La solicitud de un recurso de metadato concreto devuelve el valor correspondiente, o bien un código de error HTTP 404 - Not Found
si no se encuentra disponible el recurso.
La solicitud de un recurso de metadato general (el URI acaba en /) devuelve una lista de recursos disponibles, o bien un código de error HTTP 404 - Not Found
si no existe dicho recurso. Los elementos de la lista aparecen en líneas separadas que acaban con saltos de línea (ASCII 10).
Para las solicitudes realizadas con Servicio de metadatos de instancia versión 2, pueden aparecer los siguientes códigos de error HTTP:
-
400 - Missing or Invalid Parameters
– la solicitudPUT
no es válida. -
401 - Unauthorized
– la solicitudGET
usa un token no válido. La acción recomendada es generar un token nuevo. -
403 - Forbidden
: la solicitud no está permitida o IMDS está desactivado.
Ejemplos de recuperación de metadatos de instancia
En los siguientes ejemplos se proporcionan comandos que puede utilizar en una instancia de Windows. Para obtener los comandos que permiten recuperar los metadatos de la instancia de una instancia de Linux, consulte Recuperar metadatos de instancia en la Guía del usuario de Amazon EC2 para instancias de Windows.
Ejemplos
- Obtener las versiones disponibles de los metadatos de instancia
- Obtener los elementos de metadatos del nivel superior
- Obtener la lista de claves públicas disponibles
- Mostrar los formatos en los que se encuentra disponible la clave pública 0
- Obtener la clave pública 0 (en formato de clave OpenSSH)
- Obtener el ID de subred de una instancia
- Obtener las etiquetas de instancia de una instancia
Obtener las versiones disponibles de los metadatos de instancia
Este ejemplo obtiene las versiones disponibles de los metadatos de la instancia. Cada versión hace referencia a una compilación de metadatos de instancia correspondiente al momento en que se publicaron nuevas categorías de metadatos de instancia. No existe una correlación entre las versiones de compilación de metadatos de instancia y las versiones de la API de Amazon EC2. Tiene disponibles las versiones anteriores en caso de que tenga scripts que se basen en la estructura y la información presente en la versión anterior.
nota
Para no tener que actualizar el código cada vez que Amazon EC2 publique una nueva compilación de metadatos de instancia, se recomienda utilizar latest
en la ruta, no el número de versión. Por ejemplo, utilice latest
de la siguiente manera:
curl http://169.254.169.254/latest/meta-data/ami-id
Obtener los elementos de metadatos del nivel superior
Este ejemplo obtiene los elementos de metadatos del nivel superior. Para obtener más información, consulte Categorías de metadatos de instancia.
En los siguientes ejemplos se obtienen los valores de algunos elementos de metadatos de nivel superior del ejemplo anterior. Las solicitudes IMDSv2 usan el token almacenado creado en el comando de ejemplo anterior, siempre y cuando no haya vencido.
Obtener la lista de claves públicas disponibles
Este ejemplo obtiene la lista de las claves públicas disponibles.
Mostrar los formatos en los que se encuentra disponible la clave pública 0
Este ejemplo muestra los formatos en los que se encuentra disponible la clave pública 0.
Obtener la clave pública 0 (en formato de clave OpenSSH)
Este ejemplo obtiene la clave pública 0 (en formato de clave OpenSSH).
Obtener el ID de subred de una instancia
Este ejemplo obtiene el ID de subred de una instancia.
Obtener las etiquetas de instancia de una instancia
En los ejemplos siguientes, la instancia de ejemplo tiene etiquetas en metadatos de instancia habilitadas y las etiquetas de las instancias Name=MyInstance
y Environment=Dev
.
Este ejemplo obtiene todas las claves de etiqueta de instancia de una instancia.
En el siguiente ejemplo, se recibe el valor de la clave de Name
que se obtuvo en el ejemplo anterior. La solicitud IMDSv2 utiliza el token almacenado creado en el comando de ejemplo anterior, siempre y cuando no haya vencido.
Limitación de consultas
Limitamos las consultas a IMDS por cada instancia y aplicamos límites en el número de conexiones simultáneas desde una instancia a IMDS.
Si utiliza IMDS para recuperar credenciales de seguridad de AWS, evite consultar credenciales en cada transacción o mientras se ejecuta una gran cantidad de procesos o subprocesos, ya que puede producirse una limitación controlada en las operaciones. En lugar de ello, se recomienda guardar en caché las credenciales hasta que comience a aproximarse su caducidad. Para obtener más información sobre el rol de IAM y las credenciales de seguridad asociadas al rol, consulte Recuperar credenciales de seguridad de los metadatos de la instancia.
Si experimenta limitaciones controladas al acceder a IMDS, vuelva a realizar la consulta con una estrategia de retroceso exponencial.
Limitación del acceso a IMDS
Puede plantearse el uso de reglas de firewall locales para desactivar el acceso de algunos o todos los procesos a IMDS.
nota
En el caso de las instancias integradas en el AWS Nitro System, se puede acceder a IMDS desde su propia red cuando un dispositivo de red de la VPC, como un enrutador virtual, reenvía paquetes a la dirección de IMDS y la comprobación de origen o destino predeterminada en la instancia se encuentra deshabilitada. Para evitar que un origen externo a la VPC llegue a IMDS, se recomienda modificar la configuración del dispositivo de red a fin de eliminar paquetes con la dirección IPv4 de destino de IMDS 169.254.169.254
y, si habilita el punto de conexión IPv6, la dirección IPv6 de IMDS [fd00:ec2::254]
.
Uso del firewall de Windows para limitar el acceso
El ejemplo de PowerShell utiliza el firewall integrado de Windows para impedir que el webserver Apache (basado en el ID de usuario de instalación predeterminado de NT AUTHORITY\IUSR
) acceda a 169.254.169.254. Usa una regla de rechazo para rechazar todas las solicitudes de metadatos de instancia (IMDSv1 o IMDSv2) de cualquier proceso que se ejecute con ese usuario.
PS C:\>
$blockPrincipal = New-Object -TypeName System.Security.Principal.NTAccount ("NT AUTHORITY\IUSR")
PS C:\>
$BlockPrincipalSID = $blockPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value
PS C:\>
$BlockPrincipalSDDL = "D:(A;;CC;;;$BlockPrincipalSID)"
PS C:\>
New-NetFirewallRule -DisplayName "Block metadata service from IIS" -Action block -Direction out ` -Protocol TCP -RemoteAddress 169.254.169.254 -LocalUser $BlockPrincipalSDDL
O, puede plantearse solo dar acceso a usuarios o grupos determinados, mediante el uso de reglas de permiso. Las reglas de permiso pueden ser más sencillas de administrar desde el punto de vista de la seguridad, ya que requieren que tome una decisión acerca del software que necesita acceso a los metadatos de instancia. Si usa reglas de permiso, es menos probable que permita al software de forma involuntaria acceder al servicio de metadatos (al que no pretendía dar acceso) si posteriormente cambia el software o la configuración en una instancia. También puede combinar el uso de grupos con reglas de permiso, de manera que pueda añadir y eliminar usuarios de un grupo permitido sin tener que cambiar la regla del firewall.
El siguiente ejemplo impide acceder a los metadatos de instancia a todos los procesos que se ejecutan como grupo de SO especificado en la variable blockPrincipal
(en este ejemplo, el grupo Windows Everyone
), excepto para los procesos especificados en exceptionPrincipal
(en este ejemplo, un grupo denominado trustworthy-users
). Debe especificar los dos principios de rechazo y de permiso porque el firewall de Windows, a diferencia de la regla ! --uid-owner trustworthy-user
en iptables de Linux, no proporciona un mecanismo abreviado para permitir solo un principal determinado (usuario o grupo) mediante el rechazo de los demás.
PS C:\>
$blockPrincipal = New-Object -TypeName System.Security.Principal.NTAccount ("Everyone")
PS C:\>
$BlockPrincipalSID = $blockPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value
PS C:\>
$exceptionPrincipal = New-Object -TypeName System.Security.Principal.NTAccount ("trustworthy-users")
PS C:\>
$ExceptionPrincipalSID = $exceptionPrincipal.Translate([System.Security.Principal.SecurityIdentifier]).Value
PS C:\>
$PrincipalSDDL = "O:LSD:(D;;CC;;;$ExceptionPrincipalSID)(A;;CC;;;$BlockPrincipalSID)"
PS C:\>
New-NetFirewallRule -DisplayName "Block metadata service for $($blockPrincipal.Value), exception: $($exceptionPrincipal.Value)" -Action block -Direction out ` -Protocol TCP -RemoteAddress 169.254.169.254 -LocalUser $PrincipalSDDL
nota
Para usar reglas de firewall locales, debe adaptar los comandos de ejemplo anteriores para adaptarlos a sus necesidades.
Uso de las reglas netsh para limitar el acceso
Puede plantearse bloquear todo el software con reglas netsh
pero son menos flexibles.
C:\>
netsh advfirewall firewall add rule name="Block metadata service altogether" dir=out protocol=TCP remoteip=169.254.169.254 action=block
nota
-
Para usar reglas de firewall locales, debe adaptar los comandos de ejemplo anteriores para adaptarlos a sus necesidades.
-
Las reglas
netsh
deben establecerse a partir de un símbolo del sistema elevado y no pueden fijarse para denegar o permitir determinados principales.