Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: Add load_balancer_controller targetgroup binding only role #199
feat: Add load_balancer_controller targetgroup binding only role #199
Changes from 7 commits
c64be51
877524d
070c9f9
24f902d
02ea3e0
0c92efa
444b6aa
4ff74f2
699865f
1959a37
c203e7e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
For the
Modify*
/Register*
/Deregeister*
actions, should we not break these permissions out to avoid the wildcard, similar to the full controller policy. Something likeWith that we could even go one step further and allow users to restrict which target groups with
Where the variable
load_balancer_controller_targetgroup_names
defaults to*
. What do you think?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.
The use case for TargetGroupBinding only mode, vs. full ALB, is that you want to create (or already have pre-existing) TargetGroups outside of the kubernetes environment. This change would require the TargetGroup in question to have the elbv2.k8s.aws/cluster tag. While on one hand this solution ensures that at least the owner/creator of the TargetGroup intended for it to be updated from a load-balancer-controller, the downside is there may be valid reasons for that tag to not exist.
The second thought - your proposed change is a better version than what is documented as part of the load-balancer-controller intro guide. A person trying for the first time to use this module would quickly realize it didn't work, until they reverse engineer looking at this policy, then see that they need to go back and tag their TargetGroups with this k8s tag. I suggest that if you implement it this way, the ideal would be that the TargetBingingOnly documentation should include this more restricted version of the role vs. their more permissive one. The load-balancer-controller documentation could then describe the requirement to tag the TargetGroup.
However, the Register/Deregister change I think is brilliant. We could make an option as well for var.load_balancer_controller_targetgroup_arns if we wanted to, and then you could pass name or arn...?
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.
For now we'll proceed with what is defined by the upstream documentation. We can revisit later for any additional policy scoping