-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
Quay Enterprise
Customer has a us-east-2 backed storage for their Quay. They can't build containers by directly uploading Dockerfiles via the webform. The upload of Dockerfile fails consistently with the following error (customer info redacted):
<?xml version="1.0" encoding="UTF-8"?> <Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><AWSAccessKeyId>ASIAT...</AWSAccessKeyId><StringToSign>AWS4-HMAC-SHA256 20200520T132327Z 20200520/us-east-2/s3/aws4_request ad539c4b3...</StringToSign><SignatureProvided>99c12fda...</SignatureProvided><StringToSignBytes>41 57 53 34 2d 48 4d 41 43 2d 53 48 41 32 35 36 0a 32 30 32 30 30 35 32 30 54 31 33 32 33 32 37 5a 0a 32 30 32 30 30 35 32 30 2f 75 73 2d 65 61 73 74 2d 32 2f 73 33 2f 61 77 73 34 5f 72 65 71 75 65 73 74 0a 61 64 35 33 39 63 34 62 33 30 36 38 31 63 61 33 35 32 63 37 66 65 33 35 33 64 66 38 32 31 62 33 63 61 35 63 30 30 38 66 30 37 61 33 30 66 34 39 64 65 30 30 37 32 34 31 39 65 38 63 34 61 61 36</StringToSignBytes><CanonicalRequest>PUT /datastorage/registry/userfiles/15a2fbb1-2912-4256-b03b-0ae58a36c6d1 X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAT...P%2F20200520%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20200520T132327Z&X-Amz-Expires=300&X-Amz-Security-Token=IQoJb3JpZ2luX...;X-Amz-SignedHeaders=content-type%3Bhost%3Bx-amz-server-side-encryption content-type:application/octet-stream host:kenna-us-internal-quay.s3.us-east-2.amazonaws.com x-amz-server-side-encryption: content-type;host;x-amz-server-side-encryption UNSIGNED-PAYLOAD</CanonicalRequest><CanonicalRequestBytes>50 55 54 0a 2f 64 61 74 61 73 74 6f 72 61 67 65 2f 72 65 67 69 73 74 72 79 ...</CanonicalRequestBytes><RequestId>ABA3E3F46B9EE84A</RequestId><HostId>vx81UhmN7vCvGxVO8s4LTaLxvG6F/BydOCA6Sq7pvOE4KVLYuk5RrGz3/IMtAxN75QXjgC4eRr8=</HostId></Error>
Upon checking the bucket itself, the following is visible:
Host: [root@ip-10-127-10-114 centos]# aws s3 cp testfile s3://kenna-us-internal-quay/datastorage/registry/userfiles/ upload: ./testfile to s3://kenna-us-internal-quay/datastorage/registry/userfiles/testfile Container: [root@09bf5f9e6809 quay-registry]# aws s3 cp testfile_container s3://kenna-us-internal-quay/datastorage/registry/userfiles/ upload: ./testfile_container to s3://kenna-us-internal-quay/datastorage/registry/userfiles/testfile_container Files exist in the bucket: [root@ip-10-127-10-114 centos]# aws s3 ls s3://kenna-us-internal-quay/datastorage/registry/userfiles/ 2020-05-20 14:19:57 0 2020-05-20 15:07:53 0 testfile 2020-05-20 15:08:35 0 testfile_container
It looks like the upload scheme is using a wrong singing mechanism, although even if a bucket that has sig_v2 still enabled (such as us-east-1), the direct upload via Quay's UI is not working. The client also confirmed that this happens on Quay 3.3.0 as well.
Customer also confirmed that this issue does not happen when a Github trigger is created. The file and context is successfully copied to the bucket, fetched by the builder and the build completes without issues.
- duplicates
-
-
- Closed
-
