How to generate Cloudfront signed url for sse kms encrypted files using boto3?

Question

How can I generate a signed url for Cloudfront for sse kms encrypted files using boto3? I'm using a custom domain so that https can be used.

<Error>
<Code>InvalidArgument</Code>
<Message>
Requests specifying Server Side Encryption with AWS KMS managed keys require AWS Signature Version 4.
</Message>
<ArgumentName>Authorization</ArgumentName>
<ArgumentValue>null</ArgumentValue>
<RequestId>063D9D2F5214E53A</RequestId>
<HostId>
jVazJY0g4jSDZSKB1iYHzFz7CWGlulU3eBEmg1E2OilYURzrdKGQI0xDVCWalQWtdNYSGz/5+DM=
</HostId>
</Error>

The code below is what I was using for creating signed urls prior to using sse kms but the signed urls generated now give this error:

    def rsa_signer(message):
        private_key = open('./pk-APKAJPF6OMQQZWEXQPUA.pem', 'r').read()
        return rsa.sign(
            message,
            rsa.PrivateKey.load_pkcs1(private_key.encode('utf8')),
            'SHA-1')  # CloudFront requires SHA-1 hash

    key_id = 'APKAJPF6OMQQZWEXQPUA'
    cf_signer = CloudFrontSigner(key_id, rsa_signer)

    expires = datetime.datetime.now() + datetime.timedelta(minutes=15)
    signed_url = cf_signer.generate_presigned_url(
        url,
        date_less_than=expires)
    # ExpiresIn=100
    return signed_url

Answer 1

I don't know whether this is possible with a CloudFront pre-signed URL, at least natively. The CloudFront origin access identity creates a second signed URL (or something equivalent) behind the scenes...

CloudFront typically uses signature version 2 for authentication when it requests objects in your Amazon S3 bucket.

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html#private-content-origin-access-identity-signature-version-4

I'd have to test to be sure, but I suspect there may not be a native solution.

Modifying the request in-flight using a Lambda@Edge Origin Request trigger to generate a V4 signature and inject it might be a viable workaround, and indeed might be the only workaround.

It's also possible that if the objects were in a bucket in a region that only supports Signature Version 4, CloudFront might do the right thing, authmatically, since it does work correctly with S3 in those regions.