Fix FIPS and global endpoint behavior for S3 ARNs #2370
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #2370 +/- ##
===========================================
+ Coverage 97.03% 97.04% +0.01%
===========================================
Files 59 59
Lines 11115 11159 +44
===========================================
+ Hits 10785 10829 +44
Misses 330 330
Continue to review full report at Codecov.
|
botocore/utils.py
Outdated
| ) | ||
|
|
||
| def _validate_global_regions(self, request): | ||
| if self._s3_config.get('use_arn_region'): |
There was a problem hiding this comment.
I'd assume we would want to use self._s3_config.get('use_arn_region', True) here since by default we use the arn region? Otherwise, commands like this no longer work as they used to resolve to the us-east-1 endpoint:
$ aws s3api get-object --bucket arn:aws:s3:us-east-1:123456789012:accesspoint:myendpoint --key foo --region s3-external-1 /tmp/foo
Unsupported configuration when using S3 access-points: Invalid configuration, client region is not a regional endpoint
There was a problem hiding this comment.
I'm not sure. Looks like here we use opposite logic
Line 1811 in 92c63ea
There was a problem hiding this comment.
I double checked this, the default is True for the S3 client, but for the S3 control client it looks like it defaults to False. I think we need to stick with the default for the S3 client. Mainly if we made the default False here, we would introduce a regression where we would now fast fail if:
- The user has
AWS_S3_US_EAST_1_REGIONAL_ENDPOINT=regionalset (In v2, this environment variable no longer exists and essentially defaults to theregionalvalue). - The user does not set a region.
$ AWS_S3_US_EAST_1_REGIONAL_ENDPOINT=regional aws s3api get-object --bucket arn:aws:s3:us-east-1:123456789012:accesspoint:myendpoint --key foo /tmp/foo
Unsupported configuration when using S3 access-points: Client is configured to use the global psuedo-region "aws-global". When providing access-point ARNs a regional endpoint must be specified.
I pushed up the update in the latest commit to fix this
vz10
force-pushed
the
s3-arn-fips
branch
2 times, most recently
from
4b13643
to
1b6b95e
Compare
|
I pushed up a commit to address the feedback that I had for the previous commits. Everything else before that looked fine. |
Specifically: * Update S3 ARN validation error messages to be more explicit * Add test to block new S3 FIPS pseudo-regions * Block usage of unkonwn FIPS pseudo-regions * Have use_arn_region checks use True as the default * Add changelog entries
No description provided.