Route53 credential handling & docs

[ajschmidt8]

Lego's Route53 docs and code are a bit incomplete/confusing.

The code ultimately defers credential handling to the AWS SDK in this LoadDefaultConfig call here:

lego/providers/dns/route53/route53.go

Line 375 in 6015692

cfg, err := awsconfig.LoadDefaultConfig(ctx, optFns...)

Based on AWS's docs below, that call will load credentials from a number of different places (env vars, file system, etc.):

• https://docs.aws.amazon.com/sdk-for-go/v2/developer-guide/configure-gosdk.html#specifying-credentials
• https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/config

The Lego docs for Route53 (https://go-acme.github.io/lego/dns/route53/index.html) only mention a subset of those credential methods.

For example, I referred to the Lego docs to inquire about support for the official AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN environment variables and didn't see them. Despite the documentation omission, these environment variables work as expected since Lego leverages LoadDefaultConfig as described above.

To make matters more confusing, Lego's Route53 code includes logic to check environment variable values that it never actually fetches or uses:

lego/providers/dns/route53/route53.go

Lines 391 to 405 in 6015692

	func createAWSConfigCheckParams(config *Config) error {
	if config == nil {
	return errors.New("config is nil")
	}
	switch {
	case config.SessionToken != "" && config.AccessKeyID == "" && config.SecretAccessKey == "":
	return errors.New("SessionToken must be supplied with AccessKeyID and SecretAccessKey")
	case config.AccessKeyID == "" && config.SecretAccessKey != "" || config.AccessKeyID != "" && config.SecretAccessKey == "":
	return errors.New("AccessKeyID and SecretAccessKey must be supplied together")
	}
	return nil
	}

lego/providers/dns/route53/route53.go

Lines 365 to 369 in 6015692

	if config.AccessKeyID != "" && config.SecretAccessKey != "" {
	optFns = append(optFns,
	awsconfig.WithCredentialsProvider(credentials.NewStaticCredentialsProvider(config.AccessKeyID, config.SecretAccessKey, config.SessionToken)),
	)
	}

As far as I can tell from tracing through the code, the config.AccessKeyID, config.SecretAccessKey, etc. values are never actually read from the environment. That seems to be corroborated by the comment here:

lego/providers/dns/route53/route53.go

Lines 52 to 57 in 6015692

	// Static credential chain.
	// These are not set via environment for the time being and are only used if they are explicitly provided.
	AccessKeyID string
	SecretAccessKey string
	SessionToken string
	Region string

So my main question is...

Will Lego continue to defer to the AWS SDK for credential handling? And if so, can the docs be updated to reflect that and the dead code referenced above be removed?

I don't want this credential behavior to change unexpectedly in the future and break the undocumented AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN environment variable method that I'm currently using.

[ldez]

Hello,

lego is mainly a lib: the CLI is not the first citizen.

This explain why there are differences between the Config structure and env vars.

So this is not dead code, and it will not be removed.

I don't plan to document every env vars supported by the AWS SDK, because even the SDK itself don't do it in a synthetic and exhaustive way, and there are too many possibilities to fit in the lego documentation.

We documented the commonest usages, for the other possibilities we have the "See also" section in the documentation to provide references to the SDK possibilities.

[ldez]

Additionally, we rely on the SDK and don't plan to change that, but the SDK has several design problems that impact lego.
The AWS team is working on a new SDK (at least on a new SDK core), and lego will use this new SDK when it will be ready.

The compatibility relies on AWS team, not lego team.

In all cases, if something happen we will communicate on it and we will do our best to avoid introducing breaking changes.
Furthermore, the AWS team is relatively slow (and I understand why) to create this new SDK, so we have some time before any changes occur.

[ajschmidt8]

Sounds good! Thanks for the clarification. I hadn't considered the library use case when I read the code. Makes sense though.