IMDSv2-Unterstützung

Installation
1

Ich schreibe Ihnen, um mich nach der Unterstützung von IMDSv2 über Instanzprofile in Discourse zu erkundigen. Wir sind dabei, unseren Dienst auf die Verwendung von IMDSv2 umzustellen, da IMDSv1 keine sichere Option ist.

Wir möchten verstehen, ob Discourse derzeit IMDSv2 über Instanzprofile unterstützt und falls nicht, welche Pläne es gibt, dies in naher Zukunft zu unterstützen. Gibt es außerdem Workarounds oder Patches, die uns die Verwendung von IMDSv2 mit Discourse ermöglichen würden?

Es ist uns wichtig, sicherzustellen, dass unsere Sicherheitsanforderungen erfüllt werden, und wir glauben, dass die Verwendung temporärer Anmeldeinformationen über IMDSv2 ein kritischer Aspekt davon ist.

Das gewünschte Verhalten für den Zugriff auf Sicherheitsanmeldeinformationen, die über das Instanzprofil bereitgestellt werden, ist:

  • Eine Anwendung auf der Instanz ruft die von der Rolle bereitgestellten Sicherheitsanmeldeinformationen aus dem Instanzmetadatenelement iam/security-credentials/ rollenname ab.
  • Die Anwendung erhält die Berechtigungen für die Aktionen und Ressourcen, die wir für die Rolle definiert haben, durch die mit der Rolle verbundenen Sicherheitsanmeldeinformationen. Diese Sicherheitsanmeldeinformationen sind temporär und werden automatisch rotiert. Wir stellen neue Anmeldeinformationen mindestens fünf Minuten vor Ablauf der alten Anmeldeinformationen zur Verfügung.

Wir haben festgestellt, dass es Unterschiede zwischen den IMDSv1- und IMDSv2-Aufrufen gibt.

IMDSv1-Aufruf:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access

Während der IMDSv2-Aufruf die Verwendung eines Metadatentokens erfordert und mit den folgenden Befehlen durchgeführt werden kann:

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/iam/security-credentials/s3access

Wir würden uns über jede Information freuen, die Sie uns zur Verfügung stellen können, wie wir IMDSv2 mit Discourse verwenden können oder ob es Workarounds oder Patches gibt.

Referenz:

3

Ich bin mir keiner Möglichkeit bewusst, dass Discourse selbst IMDS verwendet. Haben Sie Discourse irgendwie auf AWS installiert? Verwenden Sie IMDSv1 bereits mit Discourse?

Was ist Ihr Anwendungsfall?

5

Ich habe einen verwandten Code gefunden.

6

Dies ist im Test-Spec.

Discourse verwendet eine Version des AWS SDK (3.130.2), die über die Mindestanforderungen hinausgeht, um IMDSv2 zu unterstützen, und soweit ich das anhand der Metrik MetadataNoToken in unseren AWS-Bereichen beurteilen kann, gibt es keine Aufrufe an IMDSv1.

Soweit ich das beurteilen kann, verwenden wir IMDSv2 bereits überall.

3 „Gefällt mir“
7

Wir haben vor einem Jahr begonnen, Discourse auf einer AWS EC2-Instanz zu verwenden. Diese Woche haben wir unsere Instanz aktualisiert, um nur IMDSv2 zu verwenden. Dies hat unsere AWS S3-Uploads mit der Fehlermeldung „unable to sign request without credentials set“ (Anfrage kann ohne gesetzte Anmeldeinformationen nicht signiert werden) unterbrochen. Wir verwenden auch die Einstellung „s3 use iam profile“.

Der lokale IMDS-Dienst wird von Discourse verwendet, um Anmeldeinformationen für andere AWS-bezogene Service-API-Aufrufe zu erhalten. Dies geschieht mit Ruby aws-sdk-s3

8

Wir sehen dieses Backup-Problem auch, nachdem wir IMDSv1 aus Sicherheitsgründen deaktiviert haben.

Wir können die Verwendung von IMDSv1 (in 3.3.0.beta1-dev) über die Metrik MetadataNoToken sehen, daher fragen wir uns, welche Version von Discourse auf die durchgängige Verwendung von v2 umgestellt hat?

9

Auch wir wurden heute davon gebissen, nachdem wir unsere AWS-Instanz auf die ausschließliche Verwendung von IMDSv2 umgestellt hatten: Unsere Benutzer konnten keine Bilder mehr nach S3 hochladen.

Wahrscheinlich relevant hier: Wir verwenden auch die Option s3 use iam profile.

Vorerst haben wir es auf “Optional” umgestellt, was im Grunde bedeutet, dass IMDSv1 immer noch aktiviert ist, was sicherheitstechnisch nicht optimal ist, aber das Hochladen funktionierte wieder.

1 „Gefällt mir“
10

Hat jemand eine Lösung/einen Workaround, damit Discourse mit IMDSv2 funktioniert?

11

Wir nehmen Änderungen vor, um mehr Konfigurationen über die Datei .aws/config zu ermöglichen/erwarten, was sich möglicherweise mit diesem überschneidet und es ermöglicht.

15

@supermathie Das Seltsamste, was ich nicht herausfinden kann, ist, dass ich persönlich 2 Discourse-Instanzen (Entwicklung/Produktion) eingerichtet habe, die identisch konfiguriert sind (S3-Uploads für Dateien und Backup mit IAM-Profil) und auf die identische Version (9436f5e3d4) aktualisiert wurden, und als ich IMDSv1 deaktivierte… in der Entwicklung funktionierte alles wie erwartet, während es in der Produktion nicht funktionierte und immer etwas wie „unable to sign request without credentials set“ ausgibt … ziemlich rätselhaft.

Wenn Sie eine Idee für Tests/Prüfungen haben, die ich durchführen könnte, lassen Sie es mich wissen.

16

@ducks hat die Timeouts im SDK für den Erwerb von IMDS-Anmeldeinformationen als sehr aggressiv (1 Sekunde, keine Wiederholungsversuche) identifiziert, sodass es möglich ist, dass dieser Timeout erreicht wird.

Aber das ist nur eine Vermutung.

Wenn Sie sich interaktiv in die Produktion einloggen können, z. B.:

discourse(prod)> c = Aws::S3::Client.new(region: ENV['DISCOURSE_S3_REGION'])
=> #<Aws::S3::Client>

discourse(prod)> c.list_objects_v2(bucket: ENV['DISCOURSE_S3_BUCKET']).contents.count
=> 1000
1 „Gefällt mir“
17

Ich habe herausgefunden, was falsch war, und ich muss mir selbst die Schuld geben, aber das Problem war ziemlich subtil.
Das Problem lag bei „HttpPutResponseHopLimit“, das auf 1 gesetzt war und es IMDSv2 nicht erlaubte, aus dem Container heraus aufgerufen zu werden.

Als ich diesen Befehl ausführte, erhielt ich diese Antwort:

> aws ec2 describe-instances --instance-ids i-00000000000000000 --query “Reservations[0].Instances[0].MetadataOptions”`
{
"State": "applied",
"HttpTokens": "optional",
"HttpPutResponseHopLimit": 1,
"HttpEndpoint": "enabled",
"HttpProtocolIpv6": "disabled",
"InstanceMetadataTags": "disabled"
}

Nach Anpassung der Einstellung lautet die korrekte Ausgabe:

> aws ec2 describe-instances --instance-ids i-00000000000000000 --query “Reservations[0].Instances[0].MetadataOptions”`
{
"State": "applied",
"HttpTokens": "required",
"HttpPutResponseHopLimit": 2,
"HttpEndpoint": "enabled",
"HttpProtocolIpv6": "disabled",
"InstanceMetadataTags": "disabled"
}

…und endlich ist das Mysterium gelöst :sweat_smile:

Vielen Dank an alle für eure Hilfe

1 „Gefällt mir“
18

Das ist großartig zu wissen!

Und hoffentlich gilt das auch für andere.

Aber ich frage mich, warum das für uns kein Problem ist. Wir haben dies auf 1 gesetzt und trotzdem funktioniert es?

discourse(prod) > ENV['AWS_EC2_METADATA_V1_DISABLED'] = 'true'
=> "true"
discourse(prod) > c = Aws::S3::Client.new(region: ENV['DISCOURSE_S3_REGION'])
=> #<Aws::S3::Client:0x00007f8b9c0e6b60>
discourse(prod) > c.config.credentials.disable_imds_v1
=> true
discourse(prod) > c.list_objects_v2(bucket: ENV['DISCOURSE_S3_BUCKET']).contents.count
=> 1000

und diese Instanz hat diese Metadaten gemäß demselben Abfragebefehl:

{
    "State": "applied",
    "HttpTokens": "optional",
    "HttpPutResponseHopLimit": 1,
    "HttpEndpoint": "enabled",
    "HttpProtocolIpv6": "disabled",
    "InstanceMetadataTags": "disabled"
}

Wir betreiben Discourse in einem Docker-Container auf EC2, genau wie andere, also … was ist der Unterschied?

19

Dieses Thema wurde nach 21 Stunden automatisch geschlossen. Neue Antworten sind nicht mehr zulässig.