Route53 should not require explicit key ID/access key, as there are other credential sources

[danielkza]

The AWS SDK can find credentials from local profiles (AWS_PROFILE env var), instance profiles, and/or environment variables. Right now it seems the R53 provider code deliberately requires passing in the credentials, which makes it impossible to use any other credential source.

AFAIK the recommended way to deal with credentials is to pass them if they are explicitly defined, but not care at all otherwise and let the SDK handle things. If no valid credentials actually exist API calls will simply fail with lack of authorization.

[captncraig]

Yeah, I kinda agree with you, I just wanna catch problems as soon as possible, and be able to tell the user what to do to fix it.

Is there a concrete set of env vars we could check or something like that?

[shortdudey123]

AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are the 2 main ones
https://github.com/aws/aws-sdk-go#configuring-credentials
http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-environment

[danielkza]

@captncraig I'm not very familiar with the Go AWS SDK, but if it's like those in other languages, it should have a DryRun flag that can be passed to API methods test credentials without performing any action. It can be used with any call that requires access to the zone being configured, and should allow immediate failure if credentials are not available.

[jcderr]

@captncraig the SDK shouldn't even need any environment variables at all; if not provided with AWS_ACCESS_KEY_ID etc, it will look for AWS_PROFILE and use that to look up credentials in ~/.aws/credentials. If that variable is not set, it'll look for a default profile in that same file...

...and if none of those work, it actually tries to make the call anyway, because EC2 Instance Profiles will inject IAM credentials into outbound calls if attached to an instance. I'm very interested in this specific use case, as we would likely manage our dnscontrol config in github, and our CI system would execute it on landed PRs; our CI system runs in EC2 and has an instance profile, allowing us to completely sidestep the need to include any secrets at all on the machine itself.

[captncraig]

That sounds reasonable. As long as auth is checked in the initializer so an appropriate error can be printed as soon as possible I'm OK with that. Possibly fetch the domain list for the account at provider initialization. Does either of you care to make a PR?

[mazzy89]

Is it then AWS_PROFILE supported? It doesn't seem so. I'd rather use Assume IAM Role rather than keys but I haven't succeed with that. Any idea?

[tlimoncelli]

I'm sorry but I don't know enough about AWS to answer that question. You might want to start a separate issue and explain the request in detail. I'd be glad to accept PRs that add that feature.