Abrufen von Instance-Metadaten - Amazon Elastic Compute Cloud

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.

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-lokale Adressen in diesem Benutzerhandbuch und unter Link-Local-Adresse auf Wikipedia.

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. Auf die IPv6-Adresse kann nur auf Instances zugegriffen werden, die auf dem AWS Nitro-System basieren, und in einem IPv6-unterstützten Subnetz (Dual-Stack oder nur IPv6).

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

IMDSv2
[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" http://169.254.169.254/latest/meta-data/
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/

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 Instance-Metadaten-Optionen.

  • Für IMDSv2 müssen Sie /latest/api/token beim 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 – Die PUT-Anfrage ist nicht gültig.

  • 401 - Unauthorized – Die GET-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.

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

IMDSv2
[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" http://169.254.169.254/ 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 2011-01-01 2011-05-01 2012-01-12 2014-02-25 2014-11-05 2015-10-20 2016-04-19 ... latest
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/ 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 2011-01-01 2011-05-01 2012-01-12 2014-02-25 2014-11-05 2015-10-20 2016-04-19 ... latest

Anfordern der Top-Level-Metadatenelemente

In diesem Beispiel werden die Metadaten-Elemente der obersten Ebene abgerufen. Weitere Informationen finden Sie unter Instance-Metadatenkategorien.

IMDSv2
[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" http://169.254.169.254/latest/meta-data/ ami-id ami-launch-index ami-manifest-path block-device-mapping/ events/ hostname iam/ instance-action instance-id instance-life-cycle instance-type local-hostname local-ipv4 mac metrics/ network/ placement/ profile public-hostname public-ipv4 public-keys/ reservation-id security-groups services/
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/ ami-id ami-launch-index ami-manifest-path block-device-mapping/ events/ hostname iam/ instance-action instance-id instance-type local-hostname local-ipv4 mac metrics/ network/ placement/ profile public-hostname public-ipv4 public-keys/ reservation-id security-groups services/

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

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

 

IMDSv2
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/reservation-id r-0efghijk987654321
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/reservation-id r-0efghijk987654321

 

IMDSv2
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/local-hostname ip-10-251-50-12.ec2.internal
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/local-hostname ip-10-251-50-12.ec2.internal

 

IMDSv2
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-hostname ec2-203-0-113-25.compute-1.amazonaws.com
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-hostname ec2-203-0-113-25.compute-1.amazonaws.com

Abrufen der Liste der verfügbaren öffentlichen Schlüssel

In diesem Beispiel wird die Liste der verfügbaren öffentlichen Schlüssel abgerufen.

IMDSv2
[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" http://169.254.169.254/latest/meta-data/public-keys/ 0=my-public-key
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/ 0=my-public-key

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.

IMDSv2
[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" http://169.254.169.254/latest/meta-data/public-keys/0/ openssh-key
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/0/ openssh-key

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

IMDSv2
[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" http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6 b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ 21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4 nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key ssh-rsa MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6 b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ 21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4 nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE my-public-key

Anfordern der Subnetz-ID für eine Instance

In diesem Beispiel wird eine Subnetz-ID für eine Instance vergeben.

IMDSv2
[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" http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id subnet-be9b61d7
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/network/interfaces/macs/02:29:96:8f:6a:2d/subnet-id subnet-be9b61d7

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.

IMDSv2
[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" http://169.254.169.254/latest/meta-data/tags/instance Name Environment
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/tags/instance Name Environment

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

IMDSv2
[ec2-user ~]$ curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/tags/instance/Name MyInstance
IMDSv1
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/tags/instance/Name MyInstance

Drosselung abfragen

Wir drosseln die Abfragen an den IMDS pro Instance und begrenzen die Anzahl gleichzeitiger Verbindungen von einer Instance zum IMDS.

Wenn Sie das IMDS zum Abrufen von AWS Sicherheitsanmeldedaten verwenden, vermeiden Sie es, bei jeder Transaktion oder gleichzeitig von einer großen Anzahl von Threads oder Prozessen nach Anmeldeinformationen abzufragen, 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

Bei Instances, die auf dem AWS Nitro-System basieren, kann das IMDS von Ihrem eigenen Netzwerk aus erreicht werden, wenn eine Netzwerk-Appliance innerhalb Ihrer VPC, z. B. ein virtueller Router, Pakete an die IMDS-Adresse weiterleitet und die standardmäßige Quell-/Zielprüfung für die Instance deaktiviert ist. Um zu verhindern, dass eine Quelle von außerhalb Ihrer VPC den IMDS erreicht, empfehlen wir Ihnen, die Konfiguration der Netzwerk-Appliance so zu ändern, dass Pakete mit der IPv4-Zieladresse des IMDS 169.254.169.254 und, falls Sie den IPv6-Endpunkt aktiviert haben, der IPv6-Adresse des IMDS verworfen werden. [fd00:ec2::254]

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-owner trustworthy-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.