Aws CloudFront Malformed Policy

Question

I have been trying to create a signed url for cloud front (that points to my s3 bucket) with limited privileges in php , but I keep getting malformed policy error.

I am using :

$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

        ]);

Basically , i want the receiver of this signed url to have only those s3 object privileges that I specify (in the code above, its set to getObject, sometimes it may be put object ,sometimes it may be delete object. How do I achieve that in cloud front ?

Answer 1

Your custom policy looks like an S3/IAM policy statement. That's not the kind of policy document that is used for CloudFront signed URLs. CloudFront has an entirely different policy language.

Custom policies in CloudFront -- technically speaking -- allow access to CloudFront , not the resources behind it. CloudFront signed URLs, and the logic that handles them, have no awareness of the entities or configuration on the back side, such as bucket names, keys, principals, origin access identities, etc... they only serve to specify that CloudFront is permitted to service requests for a specific URL or URL pattern, and nothing more. They operate strictly on the "front-side" of CloudFront, and there is no awareness at this layer of what's going on behind the scenes. If your CloudFront distribution is authorized to perform the request on the underlying resource, either because of unrestricted bucket access or because of permissions granted to the origin access identity, the operation succeeds. Otherwise, it will fail.

Review Creating a Policy Statement for a Signed URL That Uses a Custom Policy for the correct format for these policies.

Fundamentally, if you are wanting to use CloudFront signed URLs other operations against a bucket rather than GET , then you're most likely trying to use CloudFront signed URLs in a manner inconsistent with their design.

Operations other than GET , HEAD , and OPTIONS "can" be sent to S3 through CloudFront but there is only one reason to do this -- to ride the high-quality paths from the Edge network to the origin S3 location. Doing PUT through CloudFront doesn't actually store anything in CloudFront -- it just passes the request through to the bucket, and has no impact on what may already be cached in CloudFront.

You can accomplish the same purpose -- improving global network performance and throughput on non- GET operations -- by using S3 Transfer Acceleration which exposes your bucket at https://example-bucket.s3-accelerate.amazonaws.com when you enable the feature. I'm making a bit of an oversimplification, but effectively, this puts your bucket behind a generic CloudFront distribution that does not cache, allowing you to ride the Edge network for faster transfers, but still use standard S3 signatures and policies to accomplish what you need for all other S3 operations.

Or, just send the other requests directly to the bucket.