it-swarm.com.de

Amazon S3-Dateiberechtigungen, Zugriff verweigert, wenn von einem anderen Konto kopiert

Ich habe eine Reihe von Videodateien, die von einem AWS Bucket von einem anderen Konto in mein Konto in meinem eigenen Bucket kopiert wurden. 

Ich habe jetzt ein Problem mit allen Dateien, bei denen ich Fehler beim Zugriff verweigert bekomme, wenn ich versuche, alle Dateien öffentlich zu machen.

Insbesondere logge ich mich bei meinem AWS-Konto ein, gehe in S3 und durchforste die Ordnerstrukturen, um eine der Videodateien zu suchen.

Wenn ich mir diese spezifische Datei ansehe, werden auf der Registerkarte "Berechtigungen" für die Dateien keine Berechtigungen angezeigt, die jemandem zugewiesen wurden. Es wurden keine Benutzer, Gruppen oder Systemberechtigungen zugewiesen.

Am unteren Rand der Registerkarte "Berechtigungen" wird ein kleines Feld mit der Meldung "Fehler: Zugriff verweigert" angezeigt. Ich kann an der Datei nichts ändern. Ich kann keine Metadaten hinzufügen. Ich kann der Datei keinen Benutzer hinzufügen. Ich kann die Datei nicht öffentlich machen.

Gibt es eine Möglichkeit, wie ich diese Dateien kontrollieren kann, um sie öffentlich zu machen? Es gibt über 15.000 Dateien/etwa 60 GB an Dateien. Ich möchte vermeiden, dass alle Dateien heruntergeladen und erneut hochgeladen werden.

Mit etwas Unterstützung und Anregungen von den Leuten hier habe ich folgendes versucht. Ich habe in meinem Eimer einen neuen Ordner mit dem Namen "media" erstellt. 

Ich habe diesen Befehl ausprobiert: 

aws s3 cp s3://mybucket/2014/09/17/thumb.jpg s3://mybucket/media --grants read=uri=http://acs.amazonaws.com/groups/global/AllUsers full=emailaddress=my_aws_account_email_address

Beim Aufrufen der HeadObject-Operation wird ein schwerwiegender Fehler 403 angezeigt: Verboten.

13
Robbiegod

Ein sehr interessantes Rätsel! Zum Glück gibt es eine Lösung.

Zuerst eine Zusammenfassung:

  • Eimer A in Konto A
  • Eimer B in Konto B
  • Benutzer in Konto A kopiert Objekte in Bucket B (mit entsprechenden Berechtigungen).
  • Objekte in Bereich B gehören immer noch zu Konto A und kann nicht über Konto B abgerufen werden.

Ich konnte dies reproduzieren und kann bestätigen, dass Benutzer in Konto B nicht auf die Datei zugreifen können - auch nicht auf den Root-Benutzer in Konto B!

Zum Glück können Dinge behoben werden. Der Befehl aws s3 cp in der Befehlszeilenschnittstelle AWS (CLI) kann Berechtigungen für eine Datei aktualisieren, wenn er in denselben Namen kopiert wird. Um dies auszulösen, müssen Sie auch etwas anderes aktualisieren, andernfalls erhalten Sie diesen Fehler:

Diese Kopieranforderung ist unzulässig, da versucht wird, ein Objekt in sich selbst zu kopieren, ohne die Metadaten, die Speicherklasse, den Speicherort der Website oder die Verschlüsselungsattribute der Website zu ändern.

Daher können die Berechtigungen mit diesem Befehl aktualisiert werden:

aws s3 cp s3://my-bucket/ s3://my-bucket/ --recursive --acl bucket-owner-full-control --metadata "One=Two"
  • Muss von einem Konto ausgeführt werden Ein Benutzer mit Zugriffsberechtigungen für die Objekte (z. B. der Benutzer, der die Objekte ursprünglich in Bucket B kopiert hat)
  • Der Metadateninhalt ist unwichtig, aber erzwungen, um die Aktualisierung zu erzwingen
  • --acl bucket-owner-full-control erteilt die Berechtigung für Konto B, sodass Sie die Objekte normal verwenden können

Endergebnis: Ein Eimer, den Sie verwenden können!

20
John Rotenstein
aws s3 cp s3://account1/ s3://accountb/ --recursive --acl bucket-owner-full-control 
1
Achyuth

Für den Fall, dass jemand versucht, dasselbe zu tun, aber Hadoop/Spark-Job anstelle von AWS CLI verwendet.

  • Schritt 1: Gewähren Sie Benutzer in Konto A die entsprechenden Berechtigungen zum Kopieren von Objekten in Bucket B. (siehe Antwort oben)
  • Schritt 2: Legen Sie die Konfigurationsoption fs.s3a.acl.default mithilfe der Hadoop-Konfiguration fest. Dies kann in der conf-Datei oder im Programm eingestellt werden:

    Conf-Datei:

    <property> <name>fs.s3a.acl.default</name> <description>Set a canned ACL for newly created and copied objects. Value may be Private, PublicRead, PublicReadWrite, AuthenticatedRead, LogDeliveryWrite, BucketOwnerRead, or BucketOwnerFullControl.</description> <value>$chooseOneFromDescription</value> </property>

    Programmatisch:

    spark.sparkContext.hadoopConfiguration.set("fs.s3a.acl.default", "BucketOwnerFullControl")

1
Durga P. Kapa

Fügen Sie diese Bucket-Richtlinie hinzu, um die entsprechenden Berechtigungen für neu hinzugefügte Dateien korrekt festzulegen:

[...]
{
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::123456789012::user/their-user"
    },
    "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl"
    ],
    "Resource": "arn:aws:s3:::my-bucket/*"
}

Und legen Sie die ACL für neu erstellte Dateien im Code fest. Python-Beispiel:

import boto3

client = boto3.client('s3')
local_file_path = '/home/me/data.csv'
bucket_name = 'my-bucket'
bucket_file_path = 'exports/data.csv'
client.upload_file(
    local_file_path,
    bucket_name, 
    bucket_file_path, 
    ExtraArgs={'ACL':'bucket-owner-full-control'}
)

quelle: https://medium.com/artificial-industry/how-to-download-files-that-others-put-in-your-aws-s3-bucket-2269e20ed041 (Disclaimer: Von mir geschrieben)

1
Nino van Hooff

Ich fürchte, Sie können den Besitz nicht wie gewünscht übertragen. Folgendes hast du getan:

Altes Konto kopiert Objekte in neues Konto.

Die "richtige" Vorgehensweise (vorausgesetzt, Sie wollten den Besitz des neuen Kontos übernehmen) wäre:

Neues Konto kopiert Objekte aus dem alten Konto.

Sehen Sie den kleinen, aber wichtigen Unterschied? S3 docs irgendwie erklären.

Ich denke, Sie könnten damit auskommen, ohne das Ganze herunterladen zu müssen, indem Sie einfach alle Dateien in demselben Bucket kopieren und dann die alten Dateien löschen. Stellen Sie sicher, dass Sie die Berechtigungen nach dem Kopieren ändern können. Dies sollte Ihnen auch etwas Geld sparen, da Sie nicht für die Datenübertragungskosten für das Herunterladen alles zahlen müssen.

0
Viccari

durch setzen

--acl Bucket-Owner-Full-Control machte es zu arbeiten.

0