don't try to reach STS if role_arn is not specified #4681
Conversation
We should only try to reach AWS Simple Token Service is the role_arn was specified. This solves the situation where telegraf is running inside a VPC and doesn't have access to STS but is instead using IAM credentials or another auth mechanism, but auth fails because STS is unreachable
|
This code is only used to test if the authentication works, and isn't critical even with other authentication methods. I think perhaps we should just remove it altogether and rely on errors when we actually try to write. @adamchainz What do you think? |
danielnelson
added
fix
That's not quite true. It's saying the credentials are explicitly taken from STS if The check using STS is separate, and something I added because I believed STS is always reachable. Some VPC's being configured to make AWS services unreachable breaks that assumption. I agree with @danielnelson , removing the check entirely is probably the only sensible course of action. It would still leave my original issue #3319, resolved, just it's a shame configuration can't be validated at startup. |
|
I opened a PR that removes the check altogether #4695, I don't think it is worth having the check only in the rare case that the |
|
That sounds good. I'll go ahead and drop this pull request. |
When telegraf is running inside a VPC, STS (AWS Simple Token Service) may not be reachable. This makes the cloudwatch output plugin fail before it even tries other methods of getting its authentication tokens.
Since the documentation already states that STS is only tried if role_arn is specified, this patch skips STS entirely if the role_arn is blank.
Required for all PRs:
Since the change I'm making here simply makes the existing README.md true, there was no need to modify it.
I didn't add a unit test; I don't know enough about go yet to know how to mock out the sts module and the existing tests don't have a good example to copy. Assuming that's required for this change, I can learn that...