aws-config: make ProviderConfig::with_use_fips/with_use_dual_stack public#4551
Open
hligit wants to merge 1 commit intosmithy-lang:mainfrom
Open
aws-config: make ProviderConfig::with_use_fips/with_use_dual_stack public#4551hligit wants to merge 1 commit intosmithy-lang:mainfrom
hligit wants to merge 1 commit intosmithy-lang:mainfrom
Conversation
…blic `ProviderConfig::with_use_fips()` and `with_use_dual_stack()` are currently `pub(crate)`, which means external consumers that construct a `ProviderConfig` directly (via `ProviderConfig::empty()`) cannot propagate FIPS or dual-stack endpoint settings to credential providers. This is a problem for applications that need FIPS-compliant STS endpoints when using `DefaultCredentialsChain` or `AssumeRoleProvider` with a custom `ProviderConfig`. The only workaround is setting `AWS_ENDPOINT_URL_STS` as a process-global environment variable, which is not thread-safe and affects all AWS clients in the process. The top-level `ConfigLoader` already exposes `use_fips()` and `use_dual_stack()` as public methods. `ConfigLoader::load()` reads `AWS_USE_FIPS_ENDPOINT` from the environment and calls `ProviderConfig::with_use_fips()` internally. But when constructing a `ProviderConfig` directly (e.g., to supply a custom HTTP client to `DefaultCredentialsChain::builder().configure()`), the `use_fips` field defaults to `None` and there is no public API to set it. When a credential provider in the chain (e.g., `WebIdentityTokenCredentialsProvider` for EKS IRSA) needs to call STS, it builds an STS client from `ProviderConfig::client_config()`. If `use_fips` was never set, the STS client uses the non-FIPS endpoint — even if `AWS_USE_FIPS_ENDPOINT=true` is in the environment and all other AWS service clients use FIPS endpoints. Signed-off-by: Haitao Li <hli@atlassian.com>
cb4b605 to
e141ffb
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation and Context
ProviderConfig::with_use_fips()andwith_use_dual_stack()are currentlypub(crate), which means external consumers that construct aProviderConfigdirectly (viaProviderConfig::empty()) cannot propagate FIPS or dual-stack endpoint settings to credential providers.This is a problem for applications that need FIPS-compliant STS endpoints when using
DefaultCredentialsChainorAssumeRoleProviderwith a customProviderConfig. The only workaround is settingAWS_ENDPOINT_URL_STSas a process-global environment variable, which is not thread-safe and affects all AWS clients in the process.The gap:
The top-level
ConfigLoaderalready exposesuse_fips()anduse_dual_stack()as public methods.ConfigLoader::load()readsAWS_USE_FIPS_ENDPOINTfrom the environment and callsProviderConfig::with_use_fips()internally. But when constructing aProviderConfigdirectly (e.g., to supply a custom HTTP client toDefaultCredentialsChain::builder().configure()), theuse_fipsfield defaults toNoneand there is no public API to set it.The consequence:
When a credential provider in the chain (e.g.,
WebIdentityTokenCredentialsProviderfor EKS IRSA) needs to call STS, it builds an STS client fromProviderConfig::client_config(). Ifuse_fipswas never set, the STS client uses the non-FIPS endpoint — even ifAWS_USE_FIPS_ENDPOINT=trueis in the environment and all other AWS service clients use FIPS endpoints.Real-world use case:
Applications that build their own HTTP client (e.g., one backed by
rustlswithaws-lc-rsfor FIPS 140-3 compliance) and pass it toDefaultCredentialsChainviaProviderConfigcurrently have no way to ensure the internal STS calls also use FIPS endpoints:Description
ProviderConfig::with_use_fips()frompub(crate)topubProviderConfig::with_use_dual_stack()frompub(crate)topubConfigLoaderand the use caseThe diff is minimal (visibility change + doc comments only):
Testing
All 221 existing
aws-configunit tests pass (run viacargo test --libinaws/rust-runtime/aws-config). The one pre-existing failure (loader::test::provider_config_used) is an environment-dependent ANSI escape code matching issue unrelated to this change — it also fails on the unmodified parent commit.The existing integration test
e2e_fips_and_dual_stack_ssoalready exercises the FIPS endpoint resolution path throughConfigLoader.The following standalone test demonstrates the gap this PR fills. It is included here for illustration rather than as an in-tree test, since once the methods are
pubthe test is trivially testing that a setter works:Checklist
.changelogdirectory, specifying "client," "server," or both in theapplies_tokey..changelogdirectory, specifying "aws-sdk-rust" in theapplies_tokey.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.