-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(aws): use AWS profiles using .credentials file #3973
base: master
Are you sure you want to change the base?
Conversation
Welcome @roehrijn! |
Hi @roehrijn. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
c7ad1ea
to
2815f48
Compare
/ok-to-test |
42283a6
to
9e0e725
Compare
What is the value of having this complexity versus running an external-dns deployment per profile? |
/retest |
Hi @johngmyers, |
AWS profile is a feature of aws config file used in many aws compatible tools. |
Hi @mloiseleur, yes I'm going to rebase soon. Just had some other important topics on the table over the last view weeks. |
9e0e725
to
92b6089
Compare
Hi @mloiseleur, I rebased the PR. Do you see a chance to get this aspect merged? If yes, I would also take the effort to adapt the documentation accordingly. |
@roehrijn As soon as you finish and rebase this PR, I don't see why not ? Note: It surely could help too to remove the WIP in the title. |
92b6089
to
5ba3201
Compare
main.go
Outdated
if cfg.Provider == "aws" || cfg.Provider == "aws-sd" || cfg.Registry == "dynamodb" { | ||
awsSession, err = aws.NewSession( | ||
if len(cfg.AWSProfiles) == 0 || (len(cfg.AWSProfiles) == 1 && cfg.AWSProfiles[0] == "") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is a longer code change without test.
Maybe better to also have in our provider/aws package a function that creates the session instead of putting it in to main(). main() is not good testable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @szuecs, I extracted two functions, one to create sessions per profile and one to create a default session. I hope this is what you've intended. Anyway I stumbled over two aspects:
- I think the code of creating sessions over creating AWS clients to create an AWS provider can be further streamlined to remove complexity from main. I think this can all be integrated in
aws.NewAWSProvider()
. I'm eager to work on that but I guess its better to do that in a dedicated PR. WDYT? - I didn't add tests for the newly created functions. IMHO they're hard to unit test due to their strong dependencies to AWS SDK packages and behavior. However, I was wondering if you ever considered making use of LocalStack for testing the AWS provider? Same here, I would be eager to take care about that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know AWS SDK packages have a test part for mocking so you could test that at least you can instantiate a mock session, not sure if it is really helpful but a thing we could do.
I have no strong opinion on having aws.NewAWSProvider(aws.Options{..}) or something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could not find any suitable mocking option for AWS sessions in AWS SDK v1, what is still in use here. However, it turned out that in most cases session creation facilities in AWS SDK don't talk to any remote endpoint. So I was able to test the profile loading behavior from a credential file as well as the default behavior from before this PR. What is unfortunately not possible to test in this way is the role assumption options. They require connectivity to AWS' STS service.
c0993a8
to
7dd022f
Compare
d9206cf
to
5f4a13c
Compare
5f4a13c
to
fd74c25
Compare
80af5cc
to
11e098f
Compare
11e098f
to
d3fb0eb
Compare
@mloiseleur @szuecs, please let me know if there is something left to do in order to get this merged. I would be very happy to avoid further rebases if possible, because it is a lot of work to validate function and valid documentation after each rebase. I'm eager to deal with missing aspects, however it would kindly ask to get to know them all together in order to avoid extra work. |
I understand. I think we are at the end. |
/retitle feat(aws): use AWS profiles using .credentials file |
if errors.As(err, &awsErr) { | ||
switch awsErr.Code() { | ||
case "AccessDenied": | ||
log.Warnf("Skipping AWS profile %q due to missing permission: %v", profile, awsErr.Message()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this is only a warning and not fatal?
This does not seem to be a temporary issue, but requires attention so we should stop the process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please see answer on next comment. I think both have same scope, aren't they?
log.Warnf("Skipping AWS profile %q due to missing permission: %v", profile, awsErr.Message()) | ||
continue | ||
case "InvalidClientTokenId", "ExpiredToken", "SignatureDoesNotMatch": | ||
log.Warnf("Skipping AWS profile %q due to credential issues: %v", profile, awsErr.Message()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this is only a warning and not fatal?
This does not seem to be a temporary issue, but requires attention so we should stop the process.
At least I expect this to be an error instead of warning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @szuecs, thanks for the review.
In our use-case where we handle many AWS profiles with one external-dns instance, it occasionally happens that one profile is not ready due to eventual consistency topics during resource provisioning. However, the other profiles are working well in those situations. That's why we don't want the process to be killed. Especially because we heavily depend on caching in order not to face the Route53 throttling thresholds. Thats why I implemented it as a warning.
However, I understand other views on that. Changing this two cases to log an error instead of a warning would be completely fine for me. Additionally I see two more possibilities to handle that:
- In order to keep the former semantics I could log the warnings (or errors) and add fatal behavior in case none of the given profiles is working.
- I can introduce a behavioral switch as command line argument in order to let the user decide between fatal and graceful behavior (don't like that option much TBH).
WDYT?
log.Warnf("Skipping AWS profile %q due to credential issues: %v", profile, awsErr.Message()) | ||
continue | ||
default: | ||
// noting to do here. Falling through to general error handling |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so you will wrap and ignore rest of the errors by SoftError, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not say ignoring them, but yes, they're handled by NewSoftError(...)
Description
This PR introduces a new command line flag
--aws-profile
which can be used multiple times and allows to make use of AWS profiles in.credentials
files (see also Configuration and credential file settings).Furthermore the PR allows to use multiple of these profiles at once in a way that it queries for available Route53 zones using credentials of each profile and later distinguishes between the profiles in order to make changes with proper credentials to the right Route53 zone.
We at Mercedes-Benz are running a fork with those changes now for several months in production.
Checklist
Jan Roehrich jan.roehrich@mercedes-benz.com, Mercedes-Benz Tech Innovation GmbH, legal info/Impressum