Account id endpoint support #2936
Conversation
| @@ -154,6 +155,12 @@ def built_in_to_param(built_in, value) | |||
| Param.new('use_fips_endpoint', value) | |||
| when 'AWS::UseDualStack' | |||
| Param.new('use_dualstack_endpoint', value) | |||
| when 'AWS::Auth::AccountId' | |||
| Param.new( | |||
There was a problem hiding this comment.
We probably practically don't need to care about this - but what if multiple Auth builtins are set (ie, accountId + credentialScope)
There was a problem hiding this comment.
What do you mean? If both are set, they are both set as parameters. Do you mean passing in "credentials" and having something delegate to either of those?
There was a problem hiding this comment.
If both are set then we would have two credentials params which would end up not working correctly. At least as of right now, I think they would generally be mutually exclusive, so shouldn't matter...
There was a problem hiding this comment.
Talked offline, keeping as TODO when either feature is merged.
| @@ -134,6 +130,8 @@ def built_in_client_context_param_value(param_data) | |||
| else | |||
| 'context.config.use_dualstack_endpoint' | |||
| end | |||
| when 'AWS::Auth::AccountId' | |||
| "context.config.account_id_endpoint_mode == 'disabled' ? nil : context.config.credentials.credentials.account_id" | |||
There was a problem hiding this comment.
Since this logic may end up pushed into endpoint rules anyway, this probably doesn't matter - but I assume here is where we would need to warn/raise for preferred/required when account id is not set. (or rather, generate the code to do so)
There was a problem hiding this comment.
If the logic is pushed to rules, yeah, all we do is pass in the endpoint mode. I don't think we care about warning (can discuss), and raising would be done by rules, right?
|
Moved to staging repo |
Support AccountId on credentials
Support AccountId specific endpoints and a new config option account_id_endpoint_mode.
Blocked on service rules (should be passed into rules)