Aws Secret Manager connection best practices

[LahavHarary]

Hey all,
We are changing out current vault system into AWS secret manager and we have encountered a problem and a fix which we are not sure if its best practice.

We need to work with Web Identity connection for our non-local machines (such as stage and production environments) but that cannot be achieved in dev.
In order to solve this we found this article: https://www.stevejgordon.co.uk/credential-loading-and-the-aws-sdk-for-dotnet-deep-dive
Which suggest using something call a "fallsbackfactory" - Trying to connect with several connections if something doesn't work go to the next one.
We are thinking about deploying something like that into our aws connection class which will try to connect using Web-Identity tokens and if it won't work to use some other connection (which means, it will try to connect to prod/stage and then when it fails it will connect using dev).

What do you think about this solution, is there anything else we should try?

[ashishdhingra]

@LahavHarary Just to give you high level overview of FallbackCredentialsFactory:

• FallbackCredentialsFactory.GetCredentials() iterates through the list of delegates and executed them one by one until credentials are resolved.
  • For each of the executed generator, the exception is thrown and the next generator is tried.
    • BCL AppConfigAWSCredentials throws exception in constructor.
    • AssumeRoleWithWebIdentityCredentials.FromEnvironmentVariables() tries to construct AssumeRoleWithWebIdentityCredentials object, which throws exception in the constructor if certain conditions are not met.
    • GetAWSCredentials(ICredentialProfileSource source) throws exception if the profile could not be found, or, CredentialProfile. GetAWSCredentials() > AWSCredentialsFactory.GetAWSCredentials() throws an exception.
    • EnvironmentVariablesAWSCredentials() throws exception in constructor via call to FetchCredentials().
    • ECSEC2CredentialsWrapper(proxy) throws exception if certain conditions are not met, else returns new instance of ECSTaskCredentials(), OR, DefaultInstanceProfileAWSCredentials.Instance.

In each of the cases, the next generator is tried only if the previous generator returns exception in the construction process (in which case the object is never created), with ECSTaskCredentials being the last.

Looking at high level on your requirement, this approach should work. However, how do you determine the preference order in a list of (connection) generators, when it includes generator that's only applicable for DEV environment? Or should you better control generator registration logic as part of some configuration for each environment (similar to we have development and production settings for .NET configuration)? This is something you might want to evaluate per your requirements and future scalability.

Thanks,
Ashish

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.