Aws CloudFront Fehlerhafte Richtlinie

Question

Ich habe versucht, eine signierte URL für Cloud Front (die auf meine S3-Bucket zeigt) mit eingeschränkten Berechtigungen in PHP zu erstellen, aber ich bekomme immer wieder fehlerhafte Richtlinienfehler.

Ich verwende:

$customPolicy = '{"Id":"Policy1319566876317","Statement":[{"Sid":"Stmt1319566860498","Action":["s3:GetObject"],"Effect":"Allow","Resource":"arn:aws:s3:::my-bucket/*","Principal":{"CanonicalUser":["92cd670939a0460a1b48cbbfedcb5178139bcb315881d9ec3833e497a9e62959762d560feec321a749217754e5d02e5f"]}}]}'; 


// Create a signed URL for the resource using the canned policy 
     $signedUrlCannedPolicy = $cloudFront->getSignedUrl([ 
      'url'   => $streamHostUrl . '/' . $resourceKey, 
      'private_key' => base_path().'/'.'mypem file', 
      'key_pair_id' => 'myid', 
      'policy' => $customPolicy 

     ]); 

Grundsätzlich mag ich den Empfänger dieser URL nur die s3 Objektberechtigungen haben unterzeichnet, die ich (in dem obigen Code angeben, seinen Satz zu getObject, manchmal kann es sein, setzen Objekt, manchmal kann es sein Objekt löscht. Wie erreiche ich, dass in Wolkenfront?

Answer 1

Ihre benutzerdefinierte Richtlinie sieht aus wie eine S3/IAM Grundsatzerklärung. das ist nicht die Art von Politik Dokument, das für Cloudfront verwendet wird signierte URLs CloudFront hat eine völlig andere Richtliniensprache:

Benutzerdefinierte Richtlinien in CloudFront - technisch gesehen - ermöglichen den Zugriff auf CloudFront, nicht die Ressourcen dahinter. Von CloudFront signierte URLs und die Logik, mit der sie verarbeitet werden, haben keine Kenntnis von den Entitäten oder der Konfiguration auf der Rückseite, wie Bucket-Namen, Schlüssel, Principals, Identitätszugriffsidentitäten usw. Sie dienen nur dazu, CloudFront zuzulassen um Anfragen nach einem bestimmten URL oder URL-Muster zu bearbeiten, und nicht mehr. Sie arbeiten strikt an der "Vorderseite" von CloudFront, und auf dieser Ebene ist nicht bekannt, was hinter den Kulissen passiert. Wenn Ihre CloudFront-Distribution berechtigt ist, die Anforderung für die zugrunde liegende Ressource auszuführen, entweder aufgrund des unbeschränkten Bucket-Zugriffs oder aufgrund von Berechtigungen, die der Ursprungszugriffsidentität erteilt wurden, ist der Vorgang erfolgreich. Andernfalls wird es fehlschlagen.

Überprüfen Sie Creating a Policy Statement for a Signed URL That Uses a Custom Policy für das richtige Format für diese Richtlinien.

Wenn Sie CloudFront-signierte URLs mit anderen Operationen gegen einen Bucket anstatt mit GET verwenden möchten, versuchen Sie höchstwahrscheinlich CloudFront-signierte URLs in einer Weise zu verwenden, die nicht mit ihrem Design übereinstimmt.

andere Operationen als GET, HEAD und OPTIONS „können“ zu S3 über Cloudfront gesendet werden, aber es gibt nur einen Grund, dies zu tun - die hochwertigen Pfade vom Edge-Netzwerk zum Ursprung S3 Lage zu fahren. Doing PUT über CloudFront speichert eigentlich nichts in CloudFront - es reicht die Anfrage einfach an den Bucket weiter und hat keinen Einfluss auf das, was möglicherweise bereits in CloudFront zwischengespeichert ist.

Sie können das gleiche Ziel erreichen - die globale Netzwerk-Performance und Durchsatz auf nicht GET Operationen zu verbessern - durch S3 Transfer Acceleration verwendet, die bei https://example-bucket.s3-accelerate.amazonaws.com Ihre Eimer aussetzt, wenn Sie die Funktion zu aktivieren. Ich mache ein bisschen eine Vereinfachung, aber effektiv setzt dies Ihren Bucket hinter eine generische CloudFront-Verteilung, die nicht im Cache speichert, so dass Sie das Edge-Netzwerk für schnellere Übertragungen fahren können, aber immer noch Standard-S3-Signaturen und Richtlinien verwenden Notwendigkeit für alle anderen S3-Operationen.

Oder senden Sie einfach die anderen Anfragen direkt in den Eimer.