What happened to CredentialsChainVerboseErrors?

[kaihendry]

~$ go version
go version go1.9.2 linux/amd64
~$ git --git-dir ~/go/src/github.com/aws/aws-sdk-go-v2/.git describe --all
tags/v2.0.0-preview.2

What happened to CredentialsChainVerboseErrors in v1?

[jasdel]

Hi @kaihendry thanks for brining this up. this config value was removed during the V2 SDK's config refactoring. To provide this functionality back in I think we need to update how the SDK's Resolve*Credential config resolvers work. By grouping these together the new ResolveCredentials function could keep track of which resolvers fail to get credentials.

In doing so I think we need to also add a ResolveCustomCredentials config resolver so users can provide a custom credential resolver preventing the SDK's config loader from walking the other Resolve*Credentials.

DefaultAWSConfigResolvers should be updated to be:

var DefaultAWSConfigResolvers = []AWSConfigResolver{
	ResolveDefaultAWSConfig,
	ResolveCustomCABundle,

	ResolveRegion,

	BuildResolveCredentials([]CredentialResolver {
		ResolveCustomCredentials,

		ResolveCredentialsValue,
		ResolveEndpointCredentials,
		ResolveContainerEndpointPathCredentials,
		ResolveAssumeRoleCredentials,
		ResolveFallbackEC2Credentials,
	})
}

While also adding a WithCustomCredentials helper added. This would make the user experience for providing custom credentials:

cfg, err := external.LoadDefaultAWSConfig(
	externa.WithCustomCredentials(myCustomCreds), // use instead of SDK default cred chain.
)

The BuildResolveCredentials would cause config loading to fail if no credentials are resolved. Returning an error that contains the credential resolvers used, and their returned errors.

[jasdel]

After thinking about this a bit more I think a little more refactor of the way config value providers are used is needed. Basically, the concept of config source needs to be made available. The config value getter utilities need provide the list of config sources that we're consulted.

[kaihendry]

Just wanted to add that the use case with verbose credential logging is to facilitate us to build a minimal policy for a function to run. So what I'm saying is that the output should make it easy to map to a policy. Many thanks,

[jasdel]

Thanks for the update @kaihendry. Could you describe more what the feature would be making it easy to map to a policy? Would this be the output including information such as shared configuration file profile, and assume role ARN, ect?