Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Resolved
-
1.2.1
-
Ozone 1.2.1 cluster, setup with Kerberos authentication and ozone.s3g.domain.name set to ozone-host.com.
NGINX reverse proxy in front of it that accepts all <subdomain>.ozone-host.com virtual host server names and passes it forward as a host header as expected.
DNS has been suitably setup to resolve all <subdomain>.ozone-host.com to ozone-host.com.
A bucket created with name bucket.
AWS CLI client configuration setup to force virtual addressing style via addressing_style = virtual s3 sub-property.
Ozone 1.2.1 cluster, setup with Kerberos authentication and ozone.s3g.domain.name set to ozone-host.com . NGINX reverse proxy in front of it that accepts all <subdomain>.ozone-host.com virtual host server names and passes it forward as a host header as expected. DNS has been suitably setup to resolve all <subdomain>.ozone-host.com to ozone-host.com . A bucket created with name bucket . AWS CLI client configuration setup to force virtual addressing style via addressing_style = virtual s3 sub-property.
Description
When using the Virtual Style Addressing feature, the changes made to the request URI by class VirtualHostStyleFilter cause the signature to be calculated incorrectly.
The following is an example of the difference observed:
From AWS CLI, the following is the canonical request string passed for signing when contacting a virtual addressed hostname. Observe the path here to be a simple slash / when accessing a bucket named bucket (using a sub-domain, i.e. virtual addressing):
GET / delimiter=%2F&encoding-type=url&list-type=2&prefix=ls host:bucket.ozone-host.com x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 x-amz-date:20220722T062934Z host;x-amz-content-sha256;x-amz-date e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
On the service end, the canonical request string is built after the aforementioned class alters the request, parsing the host header to extract the bucket name. The string passed to class StringToSignProducer instead becomes the following. Observe that the path is now different (/bucket instead of a simple slash /):
GET /bucket delimiter=%2F&encoding-type=url&list-type=2&prefix=ls host:bucket.ozone-host.com x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 x-amz-date:20220722T062934Z host;x-amz-content-sha256;x-amz-date e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
This naturally leads to a signature validation failure because the server computes a different signature string, which then throws an invalid token error:
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.token.SecretManager$InvalidToken): Invalid S3 identifier:OzoneToken owner=root@REALM, renewer=, realUser=, issueDate=1970-01-01T00:00:00Z, maxDate=1970-01-01T00:00:00Z, sequenceNumber=0, masterKeyId=0, strToSign=AWS4-HMAC-SHA256
20220722T062934Z
20220722/us-east-1/s3/aws4_request
822555a762057e491b1ff84ae130337b4a15d72ec89f780c618f57420418bc87, signature=bc01067b738d4195e494620ce9e6b3c05961321b20356a15465fd172dd7ba474, awsAccessKeyId=root@REALM, omServiceId=null
An HTTP 500 Internal Server Error is sent to clients as a result of this exception.
Attachments
Issue Links
- links to