Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
IMDS-Versionen auf einem Snowball Edge
Mit IMDS Version 2 oder IMDS Version 1 können Sie von einer laufenden Instanz aus auf Instanz-Metadaten zugreifen:
Instance Metadata Service Version 2 (IMDSv2), eine sitzungsorientierte Methode
Instance Metadata Service Version 1 (IMDSv1), eine Anfrage-Antwort-Methode
Je nach Version Ihrer Snow-Software können Sie IMDSv2, oder IMDSv1 beide verwenden. Dies hängt auch vom Typ des AMI ab, das in der EC2 -kompatiblen Instance ausgeführt wird. Einige AMIs, z. B. solche, auf denen Ubuntu 20.04 ausgeführt wird, erfordern. IMDSv2 Der Instanz-Metadatendienst unterscheidet zwischen IMDSv1 und IMDSv2 Anfragen anhand des Vorhandenseins von PUT Oder-Headern. GET IMDSv2verwendet diese beiden Header. IMDSv1 verwendet nur den GET Header.
AWS befürwortet die Verwendung von IMDSv2 statt IMDSv1 , weil IMDSv2 beinhaltet eine höhere Sicherheit. Weitere Informationen finden Sie unter Umfassender Schutz vor offenen Firewalls, Reverse-Proxys und SSRF-Schwachstellen mit Verbesserungen am Instanz-Metadatendienst
IMDSv2 auf einer Schneeballkante
Wenn Sie IMDSv2 Instanz-Metadaten anfordern, muss die Anfrage diesen Regeln entsprechen:
Verwenden Sie eine
PUT-Anfrage, um eine Sitzung mit dem Instance-Metadaten-Service zu starten. DiePUTAnfrage gibt ein Sitzungstoken zurück, das in nachfolgendenGETAnfragen an den Instanz-Metadatendienst enthalten sein muss. Das Sitzungstoken, das die Sitzungsdauer definiert. Die Sitzungsdauer kann mindestens eine Sekunde und maximal sechs Stunden betragen. Während dieser Dauer können Sie dasselbe Sitzungstoken für nachfolgende Anfragen verwenden. Nach Ablauf dieser Dauer müssen Sie ein neues Sitzungstoken für future Anfragen erstellen. Das Token ist erforderlich, um mithilfe von auf Metadaten zuzugreifen IMDSv2.Nehmen Sie das Token in alle
GET-Anfragen an den Instance-Metadaten-Service auf.Das Token ist ein instanzspezifischer Schlüssel. Das Token ist auf anderen EC2 -kompatiblen Instances nicht gültig und wird zurückgewiesen, wenn Sie versuchen, es außerhalb der Instanz zu verwenden, auf der es generiert wurde.
Die
PUT-Anfrage muss einen Header enthalten, der die Time To Live (TTL) für das Token in Sekunden bis zu maximal sechs Stunden (21 600 Sekunden) angibt. Das Token stellt eine logische Sitzung dar. Die TTL gibt die Gültigkeitsdauer des Token und damit die Dauer der Sitzung an.Nachdem ein Token abgelaufen ist, müssen Sie eine neue Sitzung mit einer anderen
PUT-Anfrage erstellen, um auf die Instance-Metadaten zuzugreifen.Sie können auswählen, ob Sie ein Token wiederverwenden oder bei jeder Anforderung einen neues Token erstellen möchten. Für eine kleine Anzahl von Anfragen kann es einfacher sein, bei jedem Zugriff auf den Instance-Metadaten-Service ein Token zu generieren und sofort zu verwenden. Aus Effizienzgründen können Sie jedoch eine längere Dauer für das Token festlegen und es wiederverwenden, anstatt jedes Mal eine
PUT-Anfrage stellen zu müssen, wenn Sie Instance-Metadaten anfordern müssen. Es gibt keine praktische Begrenzung der Anzahl der gleichzeitigen Tokens, die jeweils eine eigene Sitzung darstellen.
HTTP GET und HEAD Methoden sind in Anfragen zu IMDSv2 Instanz-Metadaten zulässig. PUTAnfragen werden abgelehnt, wenn sie einen X-Forwarded-For Header enthalten.
Standardmäßig hat die Antwort auf PUT Anfragen ein Response-Hop-Limit (Time-to-Live) von 1 auf IP-Protokollebene. IMDS for Snow ist nicht in der Lage, das Hop-Limit für PUT Antworten zu ändern.
Das folgende Beispiel verwendet ein Linux-Shell-Skript und ruft die IMDSv2 Metadatenelemente der Instanz auf oberster Ebene ab. Dieses Beispiel:
Erstellt mithilfe der
PUTAnfrage ein Sitzungstoken mit einer Dauer von sechs Stunden (21.600 Sekunden).Speichert den Sitzungs-Token-Header in einer Variablen mit dem Namen
TOKEN.Fordert mithilfe des Tokens die Metadatenelemente der obersten Ebene an.
Verwenden Sie zwei Befehle, um das EC2 -kompatible Token zu generieren. Sie können die Befehle separat oder als einen Befehl ausführen.
Generieren Sie zuerst ein Token mit dem folgenden Befehl.
Anmerkung
X-aws-ec2-metadata-token-ttl-secondsist ein erforderlicher Header. Wenn dieser Header nicht enthalten ist, erhalten Sie den Fehlercode 400 — Fehlende oder ungültige Parameter.
[ec2-user ~]$ TOKEN=curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"
Verwenden Sie dann das Token, um mithilfe des folgenden Befehls Metadatenelemente der obersten Ebene zu generieren.
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/
Anmerkung
Wenn beim Erstellen des Tokens ein Fehler auftritt, wird in der Variablen statt eines gültigen Tokens eine Fehlermeldung gespeichert und der Befehl funktioniert nicht.
Sie können das Token speichern und die Befehle kombinieren. Das folgende Beispiel kombiniert die beiden obigen Befehle und speichert den Sitzungs-Token-Header in einer Variablen namensTOKEN.
Beispiel von kombinierten Befehlen
[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/
Nachdem Sie ein Token erstellt haben, können Sie es bis zum Ablauf wiederverwenden. Der folgende Beispielbefehl ruft die ID des AMI ab, das zum Starten der Instance verwendet wurde, und speichert sie in dem im vorherigen Beispiel $TOKEN erstellten.
Beispiel der Wiederverwendung eines Tokens
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/ami-id
IMDSv1 auf einer Schneeballkante
IMDSv1 verwendet das Request‐Response-Modell. Um Instanz-Metadaten anzufordern, senden Sie eine GET Anfrage an den Instanz-Metadatendienst.
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/
Ihre Instance-Metadaten sind in Ihrer laufenden Instance verfügbar, sodass Sie nicht die EC2 Amazon-Konsole oder die verwenden müssen AWS CLI , um darauf zuzugreifen. 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 Unterstützte Instance-Metadaten und Benutzerdaten in diesem Handbuch.
Verwenden Sie den folgenden IPv4 URI, um alle Kategorien von Instanz-Metadaten innerhalb einer laufenden Instance anzuzeigen:
http://169.254.169.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
Alle Instance-Metadaten werden als Text zurückgegeben (HTTP-Inhaltstyp text/plain).
Eine Anfrage nach einer bestimmten Metadatenressource gibt den entsprechenden Wert oder einen HTTP-Fehlercode 404 — Not Found zurück, falls die Ressource nicht verfügbar ist.
Eine Anfrage nach einer allgemeinen Metadatenressource (wenn der URI mit einem / Zeichen endet) gibt eine Liste verfügbarer Ressourcen zurück oder einen HTTP-Fehlercode 404 — Not Found, wenn es keine solche Ressource gibt. Die Listenelemente befinden sich in separaten Zeilen, die durch Zeilenvorschübe (ASCII-Zeichencode 10) abgeschlossen werden.
Für Anfragen, die mit gestellt wurden IMDSv1, können die folgenden HTTP-Fehlercodes zurückgegeben werden:
400 ‐ Fehlende oder ungültige Parameter — Die
PUTAnfrage ist nicht gültig.401 ‐ Nicht autorisiert — Die
GETAnfrage verwendet ein ungültiges Token. Die empfohlene Aktion ist das Erzeugen eines neuen Token.403 ‐ Forbidden — Die Anfrage ist nicht zulässig oder der Instanz-Metadatendienst ist deaktiviert.
