-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Reduce policy size further #11843
Reduce policy size further #11843
Conversation
edb6620
to
8e608a4
Compare
f9e48a6
to
ec5a2b5
Compare
/test pull-e2e-kops-aws-load-balancer-controller |
1 similar comment
/test pull-e2e-kops-aws-load-balancer-controller |
a896a7e
to
7420f7d
Compare
/test pull-e2e-kops-aws-load-balancer-controller |
/cc @rifelpet |
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 first commit is extremely big to review. It would be much easier if it were broken up into smaller commits.
I like to put nontrivial refactors in separate commits than semantic changes. When golden files change significantly I like to put them in an immediately following commit.
I think that was a lot of valuable input and suggestions, but perhaps out of the scope of this PR. Would be nice to get this in as the policy limit is blocking/breaking stuff right now. |
The only thing blocking is the difficulty of reviewing such a large commit. |
The code changes aren't that big, are they? For the generated output files, the changes would be fairly big even if this was done addon-by-addon. https://github.com/kubernetes/kops/pull/11843/files#diff-dfcb900da852396ff87561d730a05b2c55fb43e394e4cbe7586a913fc84c9400 gives perhaps the best idea of how this change. The new function in one go both deduplicates and sorts as a consequence of using sets. |
7420f7d
to
652e33d
Compare
652e33d
to
aad2912
Compare
I managed to follow the commits and seems fine. Now that they are split, it is a little easier. |
Some of the condition keys are changing for certain actions:
Given that some of these actions are not exercised during the e2e tests, have we confirmed these are compatible changes? The aws:ResourceTag docs mention:
which I would guess would not apply to a |
You can verify both claims on this page: https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html |
"elasticloadbalancing:DescribeRules", | ||
"elasticloadbalancing:DescribeTargetHealth", | ||
"elasticloadbalancing:DescribeListenerCertificates", | ||
"elasticloadbalancing:CreateRule", |
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.
Should this CreateRule
permission be cluster-scoped?
), | ||
Resource: resource, | ||
}) | ||
p.unconditionalAction.Insert( |
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.
Again, should some of these be cluster-scoped?
I see from the tests output that it wasn't cluster scoped before, so this is at best a follow-up item.
|
||
func createResource(b *PolicyBuilder) stringorslice.StringOrSlice { | ||
var resource stringorslice.StringOrSlice | ||
if b.ResourceARN != nil { |
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.
Should we get rid of the rest of ResourceARN
?
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: johngmyers The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This PR reduces policies by using a set for the actions that have well-known conditions (any or tagged by the cluster tag).