Abrufen von Instance-Metadaten
Da Ihre Instance-Metadaten von der ausgeführten Instance verfügbar sind, müssen Sie nicht die Amazon-EC2-Konsole oder die AWS CLI verwenden. Dies kann sehr hilfreich sein, wenn Sie ein Skript schreiben möchten, das in der Instance ausgeführt werden soll. So können Sie z. B. über die Instance-Metadaten auf die lokale IP-Adresse Ihrer Instance zugreifen, um die Verbindung zu einer externen Anwendung zu verwalten.
Instance-Metadaten werden in vier Kategorien unterteilt. Eine Beschreibung der einzelnen Instance-Metadatenkategorien finden Sie unter Instance-Metadatenkategorien.
Um alle Kategorien von Instance-Metadaten innerhalb einer laufenden Instance anzuzeigen, verwenden Sie die folgenden Pv4- oder IPv6-URIs.
IPv4
http://169.254.169.254/latest/meta-data/IPv6
http://[fd00:ec2::254]/latest/meta-data/Die IP-Adressen sind lokale Adressen (Link-local Addresses) und nur von der Instance aus gültig. Weitere Informationen finden Sie unter Link-local address
Anmerkung
In den Beispielen in diesem Abschnitt wird die IPv4-Adresse des IMDS verwendet: 169.254.169.254. Wenn Sie Zeit Instance-Metadaten für EC2-Instances über die IPv6-Adresse abrufen, stellen Sie sicher, dass Sie stattdessen die IPv6-Adresse verwenden: fd00:ec2::254. Die IPv6-Adresse des IMDS ist mit IMDSv2-Befehlen kompatibel. Die IPv6-Adresse ist nur auf Instances, die auf dem Nitro-System basieren zugänglich.
Das Befehlsformat ist unterschiedlich, je nachdem, ob Sie IMDSv1 oder IMDSv2 verwenden. Standardmäßig können Sie beide Versionen des IMDS verwenden. Um die Verwendung von IMDSv2 zu erzwingen, lesen Sie IMDSv2 verwenden.
Sie können ein Tool wie cURL verwenden (wie im folgenden Beispiel).
Informationen zum Befehl zum Abrufen von Instance-Metadaten von einer Windows-Instance finden Sie unter Abrufen von Instance-Metadaten im Amazon-EC2-Benutzerhandbuch für Windows-Instances.
Kosten
Beachten Sie, dass für HTTP-Anfragen für den Abruf von Instance-Metadaten und Benutzerdaten keine Gebühren berechnet werden.
Überlegungen
Um Probleme beim Abrufen von Instance-Metadaten zu vermeiden, sollten Sie Folgendes beachten:
-
In einer Container-Umgebung empfehlen wir, das Hop-Limit auf 2 festzulegen.
Die AWS-SDKs verwenden standardmäßig IMDSv2-Aufrufe. Wenn der IMDSv2-Anruf keine Antwort erhält, versucht das SDK den Anruf erneut und verwendet IMDSv1, falls er immer noch nicht erfolgreich ist. Dies kann zu einer Verzögerung führen, insbesondere in einer Container-Umgebung. Wenn in einer Containerumgebung das Hop-Limit 1 beträgt, wird die IMDSv2-Antwort nicht zurückgegeben, da das Gehen zum Container als zusätzlicher Netzwerk-Hop gilt. Um zu vermeiden, dass der Prozess auf IMDSv1 zurückfällt und somit die daraus resultierende Verzögerung vermeiden, empfehlen wir, dass Sie die Hop-Grenze in einer Containerumgebung auf 2 setzen. Weitere Informationen finden Sie unter Konfigurieren der Optionen für Instance-Metadaten.
-
Für IMDSv2 müssen Sie
/latest/api/tokenbeim Abrufen des Tokens nutzen.Das Ausgeben von
PUT-Anfragen an einen beliebigen versionsspezifischen Pfad, beispielsweise/2021-03-23/api/token, führt dazu, dass der Metadatenservice 403-Verboten-Fehler zurückgibt. Dieses Verhalten ist beabsichtigt. -
Wenn IMDSv2 erforderlich ist, funktioniert IMDSv1 nicht.
Sie können wie folgt überprüfen, ob IMDSv2 für eine Instance erforderlich ist: Wählen Sie die Instance aus, um deren Details anzuzeigen, und überprüfen Sie den Wert für IMDSv2. Der Wert lautet entweder Erforderlich (nur IMDSv2 kann verwendet werden) oder Optional (IMDSv2 und IMDSv1 können verwendet werden).
Antworten und Fehlermeldungen
Alle Instance-Metadaten werden als Text zurückgegeben (HTTP-Inhaltstyp text/plain).
Eine Anfrage für eine spezifische Metadatenressource gibt den entsprechenden Wert oder einen HTTP-Fehlercode 404 - Not Found zurück, wenn die Ressource nicht verfügbar ist.
Eine Anfrage für eine allgemeine Metadatenressource (der URI endet auf „/”) gibt eine Liste der verfügbaren Ressourcen oder einen HTTP-Fehlercode 404 - Not Found zurück, wenn keine entsprechenden Ressourcen vorhanden sind. Die Listenelemente stehen jeweils in einer eigenen Zeile, d. h. sie sind durch Zeilenvorschübe (ASCII 10) getrennt.
Für Anfragen, die mit Instance-Metadatenservice Version 2 gestellt werden, können die folgenden HTTP-Fehlercodes zurückgegeben werden:
-
400 - Missing or Invalid Parameters– DiePUT-Anfrage ist nicht gültig. -
401 - Unauthorized– DieGET-Anfrage verwendet ein ungültiges Token. Die empfohlene Aktion ist das Erzeugen eines neuen Token. -
403 - Forbidden– Die Anfrage ist nicht zulässig oder der IMDS ist deaktiviert.
Beispiele für das Abrufen von Instance-Metadaten
Die folgenden Beispiele enthalten Befehle, die Sie für eine Linux-Instance verwenden können. Informationen zu Befehlen zum Abrufen von Instance-Metadaten von einer Windows-Instance finden Sie unter Abrufen von Instance-Metadaten im Amazon-EC2-Benutzerhandbuch für Windows-Instances.
Beispiele
- Abrufen der verfügbaren Versionen der Instance-Metadaten
- Anfordern der Top-Level-Metadatenelemente
- Abrufen der Liste der verfügbaren öffentlichen Schlüssel
- Anzeigen der Formate, in denen der öffentliche Schlüssel 0 verfügbar ist
- Anfordern des öffentlichen Schlüssels 0 (im OpenSSH-Schlüsselformat)
- Anfordern der Subnetz-ID für eine Instance
- Abrufen von Instance-Tags für eine Instance
Abrufen der verfügbaren Versionen der Instance-Metadaten
In diesem Beispiel werden die verfügbaren Versionen der Instance-Metadaten abgerufen. Jede Version bezieht sich auf einen Instance-Metadaten-Build, wenn neue Instance-Metadatenkategorien veröffentlicht wurden. Die Build-Versionen der Instance-Metadaten korrelieren nicht mit den Amazon-EC2-API-Versionen. Es stehen frühere Versionen zur Verfügung, für den Fall dass Skripte angewendet werden, die auf den Strukturen und Daten dieser früheren Versionen aufbauen.
Anmerkung
Um zu vermeiden, dass Sie Ihren Code jedes Mal aktualisieren müssen, wenn Amazon EC2 einen neuen Instance-Metadaten-Build veröffentlicht, empfehlen wir, latest im Pfad zu verwenden, nicht die Versionsnummer. Verwenden Sie zum Beispiel latest wie folgt:
curl http://169.254.169.254/latest/meta-data/ami-id
Anfordern der Top-Level-Metadatenelemente
In diesem Beispiel werden die Metadaten-Elemente der obersten Ebene abgerufen. Weitere Informationen finden Sie unter Instance-Metadatenkategorien.
Die folgenden Beispiele zeigen die Werte einiger der Top-Level-Metadatenelemente, die im vorherigen Beispiel abgerufen wurden. Die IMDSv2-Anfragen verwenden das gespeicherte Token, das im vorhergehenden Beispielbefehl erstellt wurde (vorausgesetzt, es ist nicht abgelaufen).
Abrufen der Liste der verfügbaren öffentlichen Schlüssel
In diesem Beispiel wird die Liste der verfügbaren öffentlichen Schlüssel abgerufen.
Anzeigen der Formate, in denen der öffentliche Schlüssel 0 verfügbar ist
In diesem Beispiel werden die Formate abgerufen, in denen der öffentliche Schlüssel 0 verfügbar ist.
Anfordern des öffentlichen Schlüssels 0 (im OpenSSH-Schlüsselformat)
In diesem Beispiel wird der öffentliche Schlüssel 0 abgerufen (im Format für OpenSSH-Schlüssel).
Anfordern der Subnetz-ID für eine Instance
In diesem Beispiel wird eine Subnetz-ID für eine Instance vergeben.
Abrufen von Instance-Tags für eine Instance
In den folgenden Beispielen sind für die Beispiel-Instance Tags zu Instance-Metadaten und die Instance-Tags Name=MyInstance und Environment=Dev aktiviert.
In diesem Beispiel sind alle Instance-Tag-Schlüssel für eine Instance vorhanden.
Im folgenden Beispiel wird der Wert des Name-Schlüssel, der im obigen Beispiel erhalten wurde, angegeben. Die IMDSv2-Anfrage verwendet das gespeicherte Token, das im vorhergehenden Beispielbefehl erstellt wurde (vorausgesetzt, es ist nicht abgelaufen).
Drosselung abfragen
Wir drosseln die Abfragen an den IMDS pro Instance und begrenzen die Anzahl gleichzeitiger Verbindungen von einer Instance zum IMDS.
Wenn Sie den IMDS verwenden, um AWS-Sicherheitsanmeldeinformationen abzurufen, vermeiden Sie es, bei jeder Transaktion oder gleichzeitig aus einer großen Anzahl von Threads oder Prozessen nach Anmeldeinformationen zu suchen, da dies zu einer Drosselung führen kann. Wir empfehlen stattdessen, die Anmeldeinformationen im Cache zu speichern, bis sie sich ihrer Ablaufzeit nähern. Weitere Informationen über die IAM-Rolle und die der Rolle zugeordneten Sicherheitsanmeldeinformationen finden Sie unter Abrufen von Sicherheitsanmeldeinformationen aus Instance-Metadaten.
Wenn es beim Zugriff auf den IMDS zu einer Drosselung kommt, versuchen Sie Ihre Abfrage mit einer exponentiellen Backoff-Strategie erneut.
Begrenzen des IMDS-Zugriffs
Sie können die Verwendung lokaler Firewall-Regeln in Betracht ziehen, um den Zugriff auf den IMDS für einige oder alle Prozesse zu deaktivieren.
Anmerkung
Für Instances, die auf dem Nitro-System basieren ist IMDS ist von Ihrem eigenen Netzwerk aus erreichbar, wenn eine Netzwerk-Appliance in Ihrer VPC, z. B. ein virtueller Router, Pakete an die IMDS-Adresse weiterleitet und die standardmäßige Quelle/Zielüberprüfung für die Instance deaktiviert ist. Um zu verhindern, dass eine Quelle außerhalb Ihrer VPC IMDS erreicht, empfehlen wir, die Konfiguration der Netzwerk-Appliance so zu ändern, dass Pakete mit der Ziel-IPv4-Adresse von IMDS 169.254.169.254 und, sollten Sie den IPv6-Endpunkt aktiviert haben, die IPv6-Adresse von IMDS fd00:ec2::254, gelöscht werden.
Verwendung von iptables zur Einschränkung des Zugriffs
Das folgende Beispiel verwendet Linux-iptables und sein owner-Modul, um zu verhindern, dass der Apache-Webserver (basierend auf seiner Standardinstallationsbenutzer-ID von apache) auf 169.254.169.254 zugreift. Es verwendet eine Verweigerungsregel, um alle Instance-Metadatenanfragen (ob IMDSv1 oder IMDSv2) von jedem Prozess abzulehnen, der als dieser Benutzer ausgeführt wird.
$sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner --uid-owner apache --jump REJECT
Oder Sie können erwägen, nur bestimmten Benutzern oder Gruppen Zugriff zu gewähren, indem Sie Zulassungsregeln verwenden. Zulassungsregeln können aus Sicherheitssicht einfacher zu verwalten sein, da Sie eine Entscheidung darüber treffen müssen, welche Software Zugriff auf Instance-Metadaten benötigt. Wenn Sie Zulassungsregeln verwenden, ist es weniger wahrscheinlich, dass Sie Software versehentlich den Zugriff auf den Metadaten-Service erlauben (auf den sie nicht zugreifen soll), wenn Sie später die Software oder Konfiguration auf einer Instance ändern. Sie können außerdem Gruppen mit Zulassungsregeln kombinieren, sodass Sie Benutzer zu einer zugelassenen Gruppe hinzufügen und aus dieser entfernen können, ohne die Firewall-Regel ändern zu müssen.
Das folgende Beispiel verhindert den Zugriff auf den IMDS durch alle Prozesse, mit Ausnahme von Prozessen, die im Benutzerkonto trustworthy-user ausgeführt werden.
$sudo iptables --append OUTPUT --proto tcp --destination 169.254.169.254 --match owner ! --uid-ownertrustworthy-user--jump REJECT
Anmerkung
-
Um lokale Firewall-Regeln zu verwenden, müssen Sie die vorhergehenden Beispielbefehle an Ihre Bedürfnisse anpassen.
-
Standardmäßig sind iptables-Regeln nicht über Systemneustarts hinweg persistent. Sie können durch die Verwendung von Betriebssystemfeatures, die hier nicht beschrieben werden, persistent gestaltet werden.
-
Das iptables
owner-Modul überprüft nur dann die Gruppenzugehörigkeit, wenn die Gruppe die Primärgruppe eines bestimmten lokalen Benutzers ist. Andere Gruppen werden nicht abgeglichen.
Verwendung von PF oder IPFW zur Einschränkung des Zugriffs
Wenn Sie FreeBSD oder OpenBSD verwenden, können Sie PF oder IPFW verwenden. Die folgenden Beispiele beschränken den Zugriff auf den IMDS auf den Root-Benutzer.
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
Anmerkung
Die Reihenfolge der PF- und IPFW-Befehle ist von Bedeutung. PF verwendet standardmäßig die letzte übereinstimmende Regel und IPFW die erste übereinstimmende Regel.
