-
Notifications
You must be signed in to change notification settings - Fork 288
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
[release-0.19] Backporting dependency bumps to fix vulnerabilities #8118
[release-0.19] Backporting dependency bumps to fix vulnerabilities #8118
Conversation
`controller-runtime` v0.16.5 - Fake client breaking changes: - Start using `WithStatusSubresource` when we care about status being treated differently through `Update` calls. This is basically all controllers. - Add a finalizer when creating an object directly with a deletion timestamp. This make sense since any controller interested in the delete flow should be already adding finalizers. - Signature of `Watches` for creating a controller has been simplified and doesn't need the `source.Kind` wrapper. - Manager options signature has changed. Now metrics and webhook fields are nested in its own second level struct. - Validation webhooks now return a `(admission.Warnings, error)` instead of just `error`. We are not using this functionality for now, but we had to update all our webhooks and test to follow the new signature. - `handler.MapFunc` has changed, now they take a context as well. We don't use the context but need to conform to the new signature. `cluster-api` v1.6.2 - When setting up cluster tracker, the variable `DefaultIndexes` is removed, now we use `[]Index{NodeProviderIDIndex}` CAPC We are still waiting for capc to be updated to capi v1.5, which would enable us to move to controller-runtime v0.15. It's taking quite long and we got to the point where this is preventing us from updating moduled (like helm) that we need to update ASAP. I opted for "vendoring" just the api structs we need from capc. In order to contain changes and allow for an easy "revert" to use the original module (whenever we can), I created a dummy module so I can just use a `replace` in our go.mod and point to our vendored folder. I put this in `internal/thirdparty/capc`. You don't need to review that code, I just copied it. Assertions in gomock I had to change some of the assertions in the cluster manager tests. Now they are less strict since they use type instead of content assertion. TBH, they were wrong from the beginning since they expected current and new spec to be the same, so if so, this makes the test slightly better. I checked and I believe all this is already dead code because of the workflow refactors we did in v0.19.0. It's just that the code hasn't been deleted yet. I'll push to get all this crap removed. CAPV They just change the package where they have the api structs from `api/[version]` to `apis/[version]`.
bump helm and controller runtime
bump net/x to fix vulnerability
3030c85
to
5d80e1b
Compare
4e30a79
to
32b2a83
Compare
32b2a83
to
20a19b0
Compare
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cxbrowne1207 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 |
Code patch is failing, but all the changes here are simply backports. Manually merging |
Issue #, if available:
Description of changes:
This PR fixes the vulnerability against the release-0.19 branch: https://github.com/aws/eks-anywhere/actions/runs/8919770915/job/24496803340
We disabled the vulnerability scan for some time, but after we re-enabled we’ve seen the scan identify more issues. One of the dependencies we need to bump to a good version to pass the scan is helm. But it requires a few cascading changes as well we have to upgrade. Most notably controller-runtime, which also requires upgrading:
The helm vulnerability was only moderate in severity.
If we do this upgrade, we would have to watch the next patch release closely for failures with such a massive change (and possibly rollback or back-port other fixes that have been made to main). I did run these changes against the release-0.19 branch and the quick-e2e, but without running haven’t tested against the full suite. If we don’t do these bumps, the vulnerability checks against the release branch will not pass.
I think if we don’t, we should consider disabling checks on the release branches entirely, but this comes with the risk of not being alerted to necessary CVE fixes that could affect these branches. Additionally, addressing these issues as they come up could lead to complex changes when there does need to be a fix that needs backported.
The PR manually cherry picks of the following PRs:
Bump controller-runtime to v0.16.5: #7788
Bump helm to v3.14.2: #7797
Bump x/net: #7945
Bump Go version to 1.21: #7805
Bump helm from 3.14.2 to 3.14.4: #8119
Testing (if applicable):
Ran changes against quick E2E tests on the release branch.
Documentation added/planned (if applicable):
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.