Ich versuche, einen bestehenden Discourse-Server in eine neue AWS-basierte Umgebung zu migrieren und Uploads in S3 in einem Bucket zu speichern, der serverseitige Verschlüsselung mit kundenverwalteten Schlüsseln (SSE-C) verwendet. Während des Wiederherstellungsprozesses werden die Uploads nicht in S3 übertragen – jeder einzelne Upload schlägt fehl. Durch den gezielten Einsatz von tap|p-Debugging habe ich festgestellt, dass der Upload zwar erfolgt, aber die Validierung des zurückgegebenen etag fehlschlägt, da der von S3 nach dem Upload zurückgegebene etag jedes Mal anders ist. Zum Beispiel ist dies der Rückgabewert des Aufrufs put_object bei zwei verschiedenen Wiederherstellungsversuchen:
# Lauf 1
# <struct Aws::S3::Types::PutObjectOutput expiration=nil, etag="\"d49ec2006cfd6fe957af2f711edd9a4b\"", checksum_crc32=nil, checksum_crc32c=nil, checksum_sha1=nil, checksum_sha256=nil, server_side_encryption="aws:kms", version_id="xAF23wQ.zwpoxVmmGiTjxfX0svMZbHAe", sse_customer_algorithm=nil, sse_customer_key_md5=nil, ssekms_key_id="**redacted**", ssekms_encryption_context=nil, bucket_key_enabled=true, request_charged=nil>
# Lauf 2:
# <struct Aws::S3::Types::PutObjectOutput expiration=nil, etag="\"05edffee421c6aef950b3d4418ada293\"", checksum_crc32=nil, checksum_crc32c=nil, checksum_sha1=nil, checksum_sha256=nil, server_side_encryption="aws:kms", version_id="H2_8SVh.Yx2LKB4GIjhyPbVoj_.Vc1E2", sse_customer_algorithm=nil, sse_customer_key_md5=nil, ssekms_key_id="**redacted**", ssekms_encryption_context=nil, bucket_key_enabled=true, request_charged=nil>
(Ich weiß, dass es sich um dieselben Dateien handelt, da ich auch die clientseitige MD5-Summe und die put_object-Anforderungsoptionen ausdrucke, die den Dateinamen enthalten.)
Es stellt sich heraus, dass der ETag-Antwortheader sich… anders verhält, wenn SSE-C verwendet wird:
Objekte, die mit serverseitiger Verschlüsselung mit kundenbereitgestellten Schlüsseln (SSE-C) oder AWS Key Management Service (AWS KMS)-Schlüsseln (SSE-KMS) verschlüsselt sind, haben ETags, die keine MD5-Digest ihrer Objektdaten sind.
Die einzige Möglichkeit, die ich finden kann, um die Integrität von Uploads mit SSE-C zu überprüfen, besteht darin, den Content-MD5-Anforderungsheader zu senden und S3 die Korruptionserkennung durchführen zu lassen. Beachten Sie auch, dass die Prüfung auf bereits hochgeladene Dateien ebenfalls fehlschlägt, wenn SSE-C verwendet wird, aber zumindest kann diese durch SKIP_ETAG_VERIFY deaktiviert werden.
Ich reiche keinen PR ein, da es zwei verschiedene Ansätze gibt:
- Erweitern Sie einfach
SKIP_ETAG_VERIFY, um die Überprüfung nach dem Upload einzuschließen, was billig und hacky ist und erfordert, dass Benutzer wissen, dass sie diese Option aktivieren müssen, wenn sie SSE-C verwenden. oder - Wechseln Sie zur Verwendung des Content-MD5-Headers (vorzugsweise immer) zur Integritätssicherung von Uploads, was den Vorteil hat, dass es für alle funktioniert, auf Kosten eines weitaus größeren PR.
(Nebenbei bemerkt, bin ich ziemlich beunruhigt, dass niemand dies zuvor getroffen hat – verwendet niemand Discourse mit SSE-C für Uploads?!?)
