2016-08-17 2 views
2

Ich versuche, allgemeinen Zugriff auf einen Bucket mithilfe einer S3-Bucket-Richtlinie bereitzustellen und gleichzeitig den spezifischen Zugriff auf eine Rolle mithilfe einer Rollenrichtlinie zuzulassen. Die Rolle wird von einer Lambda-Funktion zum Behandeln von Objekten im Bucket verwendet. Es wird an der ersten Hürde gestoppt - es kann nichts mit dem Präfix "incoming /" erhalten werden, obwohl es in der Rollenrichtlinie erlaubt ist und nicht explizit in der Bucket-Richtlinie verweigert wird.S3-Bucket-Richtlinie und IAM-Rollenkonflikt

Role-Politik:

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
     { 
      "Sid": "AllowBucketPut", 
      "Effect": "Allow", 
      "Action": [ 
       "s3:PutObject" 
      ], 
      "Resource": "arn:aws:s3:::bucket-name/*" 
     }, 
     { 
      "Sid": "AllowIncomingGetDelete", 
      "Effect": "Allow", 
      "Action": [ 
       "s3:GetObject", 
       "s3:DeleteObject" 
      ], 
      "Resource": "arn:aws:s3:::bucket-name", 
      "Condition": { 
       "StringLike": { 
        "s3:prefix": "incoming/*" 
       } 
      } 
     } 
    ] 
} 

Hinweis: Ich habe auch versucht, den Zustand zu entfernen und die Änderung der Ressource "arn: aws: s3 ::: eimer Name/incoming *", die nur zu ändern schien wie der Richtliniensimulator hat sich verhalten. Noch eine Anmerkung: GET aus dem Eimer mit "incoming/*" Präfix funktioniert im Simulator, nur nicht in der Praxis.

Ich habe keine Aussagen in der folgenden Bucket-Richtlinie entfernt, da ich nicht sicher bin, was relevant sein könnte. IP-Adressen wurden weggelassen.

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
     { 
      "Sid": "AllowPublicList", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "*" 
      }, 
      "Action": "s3:ListBucket", 
      "Resource": "arn:aws:s3:::bucket-name", 
      "Condition": { 
       "StringLike": { 
        "s3:prefix": "public*" 
       } 
      } 
     }, 
     { 
      "Sid": "AllowPublicGet", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "*" 
      }, 
      "Action": "s3:GetObject", 
      "Resource": "arn:aws:s3:::bucket-name/public*" 
     }, 
     { 
      "Sid": "AllowPrivateList", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "*" 
      }, 
      "Action": "s3:ListBucket", 
      "Resource": "arn:aws:s3:::bucket-name", 
      "Condition": { 
       "StringLike": { 
        "s3:prefix": "private*" 
       }, 
       "IpAddress": { 
        "aws:SourceIp": [ 
         "..." 
        ] 
       } 
      } 
     }, 
     { 
      "Sid": "AllowPrivateGet", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "*" 
      }, 
      "Action": "s3:GetObject", 
      "Resource": "arn:aws:s3:::bucket-name/private*", 
      "Condition": { 
       "IpAddress": { 
        "aws:SourceIp": [ 
         "..." 
        ] 
       } 
      } 
     }, 
     { 
      "Sid": "AllowIncomingPut", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "*" 
      }, 
      "Action": "s3:PutObject", 
      "Resource": "arn:aws:s3:::bucket-name/incoming*", 
      "Condition": { 
       "IpAddress": { 
        "aws:SourceIp": [ 
         "..." 
        ] 
       } 
      } 
     } 
    ] 
} 

Entschuldigung für die Wand des Textes.

Ich verstehe nicht, warum meine Rolle nicht Objekte mit dem Präfix "incoming /" abrufen kann.

Die Lambda-Funktion wird immer 403 Zugriff verweigert, wenn die folgenden Aktionen ausführen:

versuchen
S3.download_file(bucket, key, localfile) 

Antwort

0

Können Sie die unten Anweisung, um den Eimer Richtlinie hinzufügen?

{ 
     "Sid": "AllowIncomingGet", 
     "Effect": "Allow", 
     "Principal": { 
      "AWS": "*" 
     }, 
     "Action": "s3:GetObject", 
     "Resource": "arn:aws:s3:::bucket-name/incoming/*", 
     "Condition": { 
      "IpAddress": { 
       "aws:SourceIp": [ 
        "..." 
       ] 
      } 
     } 
    } 
4

Gemäß der Dokumentation (http://docs.aws.amazon.com/AmazonS3/latest/dev/amazon-s3-policy-keys.html), die s3:prefix Bedingungen gelten für die s3:ListBucket API nur, um den Anrufer zu zwingen, einen Präfix auf der ListBucket Operation zu spezifizieren. Es scheint nicht für einen API-Aufruf GetObject zu gelten.

Diesem Grund, Ihre Allow auf GetObject mit der Bedingung s3:prefix == ... keine GET (Object) Anfragen werden übereinstimmen (da diese Anfragen enthalten nicht die Politik der Schlüssel! „S3: Vorsilbe“), so dass Sie nicht wirksam sind Zulassen dieser Anforderungen in der Role-Richtlinie. Da Sie diese Anforderung in der Bucket-Richtlinie auch nicht zuzulassen scheinen und es an keiner Stelle Verweigerungsanweisungen gibt, wird Ihr Lambda-Code implizit verweigert.

Sie sollten stattdessen eine Resource verwenden, wie Sie bereits erwähnt haben Sie auf der Politik Simulator versucht: "Resource": "arn:aws:s3:::bucket-name/incoming/*".

Auch - Sie haben vielleicht einen Grund, die Richtlinien genau wie Sie, aber es scheint ein wenig ungewöhnlich -, typischerweise die "Resource" Element auf S3-bezogenen Richtlinien, wenn Sie ein Präfix beschreiben wollen, sein wird etwas wie ...incoming/*, anstatt nur ...incoming*. Dies könnte einige unerwartete Ergebnisse verhindern. Angenommen, Sie haben einen "Ordner" namens incoming/ und später erstellen Sie einen Ordner mit dem Namen incoming-top-secret/. So wie Sie die Richtlinie geschrieben haben, gewähren Sie Zugriff auf diese beiden Präfixe! Aber noch einmal - ohne genau die genauen Details Ihrer Umgebung zu kennen, ist es schwer zu sagen, was Sie wirklich brauchen. Ich wollte nur sicherstellen, dass Sie (und alle anderen, die das hier lesen) sich dieses subtilen (aber wichtigen) Details bewusst sind!

Das ist alles, woran ich denken kann, basierend auf der Beschreibung, die Sie gegeben haben. Wenn Sie diese Änderungen versuchen und es immer noch nicht funktioniert, aktualisieren Sie Ihre Frage entsprechend mit den neuen Richtlinien, die Sie versucht haben.Viel Glück!

+0

Vielen Dank für die Klarstellung. Wie im Post erwähnt, bekomme ich das gleiche Verhalten, indem ich die Ressource beschreibe, die Sie beschreiben. Ich habe das Problem herausgefunden ... irgendwie. Ich werde aktualisieren, wenn ich wieder bei der Arbeit bin. – unclemeat