-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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
AWS: Remove obsolete permissions on ELB security group #21987
Conversation
Labelling this PR as size/L |
GCE e2e test build/test passed for commit aaa8c36beb556e505b74f1038e49ffa3b8ffd731. |
PR needs rebase |
Ok, 21907 is lgtm'd, i plan on reviewing this tomorrow. |
Labelling this PR as size/XL |
Thanks @mikedanese ... #21907 got caught up in the merge problems last night (#22435). But I'm trying to push it through... I did rebase this on the LGTMed #21907, so hopefully 21907 will go through shortly (it just made it back onto the submit queue) and then this one should be clean. This PR is going to just be for the final commit. |
GCE e2e build/test passed for commit d9386e3545b5e8c90fcca3006431fe00d6873160. |
|
||
type IPPermissionSet map[string]*ec2.IpPermission | ||
|
||
func NewIPPermissionSet(items ...*ec2.IpPermission) IPPermissionSet { |
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.
Was this autogenerated? cc @lavalamp
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.
It wasn't - we can't currently autogenerate things that can't be map-keys. We had the same thing in #21907 for sets of net.IPNet. There we ended up putting it into pkg/util/net/sets, expected alias for the import being netsets, with a readme that we will likely move it to pkg/util/sets when/if we get autogen to work. And the API for netsets.IPNet should match the API for sets, at least as much as is implemented.
This one is AWS only, so I don't think we should let it escape pkg/cloudproviders/providers/aws.
IIUC this makes it so people can't add their own rules to a security group. I think theirs a use case for being able to add your own rules to the k8s security group, and also seems like it might break someone if they upgrade and had been using manually created rules. |
Ahh different security groups for elbs than nodes so last point probably doesn't make sense right? |
Good observation. Yes, you can't (or you can't expect them to survive).
The way around this that I've been pushing is to have two security groups on your ELBs/instances. The one that is tagged with the KubernetesCluster tag is owned by kubernetes, and abandon hope all you who enter there. But k8s will not touch the second security group, and if you want to add your own rules, that is where you would do that. In general though, I think going behind k8s's back and doing stuff directly in the API is not something we can support generally. You should expect that a future version of k8s will reconcile your changes to the k8s state of the world, as k8s adds more and more functionality. We can carve out exceptions which we will allow, like "if you want to change security group rules manually on an ELB, add a second security group".
Yes. But upgrades are non-existent right now anyway on AWS... still hoping to get to it for 1.2. |
No, I think it makes just as much sense to add a security group rule to a node as to an ELB :-) Arguably #21907 reduces the need for the ELB case, but there's always an exception... |
That sounds fine |
The ingress CIDRs are going to be dynamic, and in general we don't want to leave old ingress rules around. Fix kubernetes#21895
Added a comment that we should probably regroup rules in future, and rebased so there is only 1 commit now in this PR. Also #21907 has now merged so this is now mergeable if you approve @mikedanese |
Labelling this PR as size/L |
GCE e2e build/test passed for commit 62e34da. |
Fixes a P1 so marking as P1 |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e build/test passed for commit 62e34da. |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e build/test passed for commit 62e34da. |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e build/test passed for commit 62e34da. |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e build/test failed for commit 62e34da. Please reference the list of currently known flakes when examining this failure. If you request a re-test, you must reference the issue describing the flake. |
GCE e2e build/test passed for commit 62e34da. |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e build/test passed for commit 62e34da. |
Automatic merge from submit-queue |
Auto commit by PR queue bot
The ingress CIDRs are going to be dynamic, and in general we don't want
to leave old ingress rules around.
Fix #21895
Depends on #21907