New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What happened to CredentialsChainVerboseErrors? #98

Open
kaihendry opened this Issue Jan 16, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@kaihendry
Copy link

kaihendry commented Jan 16, 2018

~$ 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

This comment has been minimized.

Copy link
Member

jasdel commented Jan 17, 2018

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

This comment has been minimized.

Copy link
Member

jasdel commented Jan 17, 2018

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

This comment has been minimized.

Copy link

kaihendry commented Jan 31, 2018

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

This comment has been minimized.

Copy link
Member

jasdel commented Jan 31, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment