Print the profile being used before attempting to authenticate about eksctl

[errordeveloper]

So, if you get an error like "dialout i/o timeout" it may be DNS timing out. Not sure if this is worth highlighting in a separate ticket, as a user-aide error message.

Typica with Go, I get these from kubectl once in a while, my Virgin Media ISP also has crappy DNS. I've filed an issue once – kubernetes/kubernetes#33877, not sure what's been done about. We can probably find something to do about it and make a PR to kubectl (or Go?), i.e. match timeout error and make the message more useful.

[crw]

Sidebar, the reason I was doing the debugging is Comcast DNS servers we timing out on certain AWS domain names (but not others). So, eksctl didn't work, but I could reach other k8s clusters on aws and gke (but my Plume wifi devices, which dial home to an AWS domain, had been offline for a week for the same reason).

So, if you get an error like "dialout i/o timeout" it may be DNS timing out. Not sure if this is worth highlighting in a separate ticket, as a user-aide error message.

[errordeveloper]

Turns out this is pretty complicated, the SDK has a lot of logic to deal with different configuration modes, however there is no way to obtain profile being used. We can get credentials struct, but it doesn't have profile in it as such. Also, there is a mode where profile isn't even set, i.e. you just have credentials set as environment variables and no ~/.aws/credentials file.

I think the most sensible way would be to expose a flag that would let you set profile explicitly to avoid any doubts about environment variables or anything else.

[errordeveloper]

Maybe we could print a sanitised credentials struct, e.g.:

2018-06-10T08:54:23-07:00 [▶]  AWS credentials: AccessKeyID:"AIF***VA2A", SecretAccessKey:"6Bhg***B3LX", SessionToken:"GN8DCY***hD", ProviderName:"SharedConfigCredentials: /Users/ilya/.aws/credentials"

[crw]

I would probably skip showing secret stuff (SecretAccessKey, SessionToken), even in an elided format. Otherwise, LGTM.

[errordeveloper]

We have --profile now, it should help to eliminate doubts. The fundamental issues is that credentials may be set without any profile as such, so the SDK doesn't have a way to tell us anything about profile used... Closing for now, open if you disagree :)