1. If the configured credentials are invalid (non-empty but unusable), it looks like the role will be used instead, which could produce surprising results if the operator isn't expecting it
2. If the configured credentials are valid, and the magic AWS env vars are invalid (non-empty but unusable), setup will fail -- even though the magic env vars wouldn't end up being used if they were valid (at least this is my impression after skimming the source code for session.NewSession())
3. It's not obvious to me what the error message will be for the "invalid credentials + no IAM role" case

None of this seems wrong per se, but might be worth mentioning explicitly in config.default.yml that we will try the explicit credentials first, then fall back to IAM role.

Other than that minor thing, LGTM!

Tom Clegg wrote:

There seem to be a couple of not-quite-obvious behaviors:

1. If the configured credentials are invalid (non-empty but unusable), it looks like the role will be used instead, which could produce surprising results if the operator isn't expecting it

Actually, no, if invalid credentials are specified in the config file, a-d-c prints the following type of error in the logs and does not try to use the next authentication method:

Jan 21 19:14:27 tordo.arvadosapi.com arvados-dispatch-cloud¹⁴²⁴: {"PID":1424,"error":"AuthFailure: AWS was not able to validate the provided access credentials\n\tstatus code: 401, request id: d32a9139-4827-480f-947f-151e7c449557","level":"warning","msg":"sync failed","time":"2021-01-21T19:14:27.969809836Z"}

If the credentials are empty (i.e. defined in config file but zero-length value), the role authentication method will be used.

1. If the configured credentials are valid, and the magic AWS env vars are invalid (non-empty but unusable), setup will fail -- even though the magic env vars wouldn't end up being used if they were valid (at least this is my impression after skimming the source code for session.NewSession())

AWS-specific environment values are a different method to supply authentication information, and we don't support that method. So we probably don't need to worry about this scenario.

1. It's not obvious to me what the error message will be for the "invalid credentials + no IAM role" case

See above, the IAM role does not come into play.

None of this seems wrong per se, but might be worth mentioning explicitly in config.default.yml that we will try the explicit credentials first, then fall back to IAM role.

Other than that minor thing, LGTM!

Aha. The "chain" thing looked like it might try each method until one worked. But evidently it does the more predictable thing. And, agreed, the env vars seem like they won't interfere with anything in practice. So... LGTM

Tom Clegg wrote:

Aha. The "chain" thing looked like it might try each method until one worked. But evidently it does the more predictable thing. And, agreed, the env vars seem like they won't interfere with anything in practice. So... LGTM

Thanks will merge!