stable 2.13.7 #11398
Merged
stable 2.13.7 #11398
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Bump CNI plugin to v1.2.1 * Bump proxy-init to v2.2.2 Both dependencies include a fix for CVE-2023-2603. Since alpine is used as the runtime image, there is a security vulnerability detected in the produced images (due to an issue with libcap). The alpine images have been bumped to address the CVE. Signed-off-by: Matei David <[email protected]>
* stopgap fix for hostport staleness Problem: When there's a pod with a `hostPort` entry, `GetProfile` requests targetting the host's IP and that `hostPort` return an endpoint profile with that pod's IP and `containerPort`. If that pod vanishes and another one in that same host with that same `hostPort` comes up, the existing `GetProfile` streams won't get updated with the new pod information (metadata, identity, protocol). That breaks the connectivity of the client proxy relying on that stream. Partial Solution: It should be less surprising for those `GetProfile` requests to return an endpoint profile with the same host IP and port requested, and leave to the cluster's CNI to peform the translation to the corresponding pod IP and `containerPort`. This PR performs that change, but continuing returning the corresponding pod's information alongside. If the pod associated to that host IP and port changes, the client proxy won't loose connectivity, but the pod's information won't get updated (that'll be fixed in a separate PR). A new unit test validating this has been added, which will be expanded to validate the changed pod information when that gets implemented. Details of Change: - We no longer do the HostPort->ContainerPort conversion, so the `getPortForPod` function was dropped. - The `getPodByIp` function will now be split in two: `getPodByPodIP` and `getPodByHostIP`, the latter being called only if the former doesn't return anything. - The `createAddress` function is now simplified in that it just uses the passed IP to build the address. The passed IP will depend on which of the two functions just mentioned returned the pod (host IP or pod IP)
This stable releases addresses backports two fixes that address security vulnerabilities. The proxy's dependency on the webpki library has been updated to patch [RUSTSEC-2023-0052], a potential CPU usage denial-of-service attack when accepting a TLS handshake from an untrusted peer. In addition, the CNI and proxy-init images have been updated to patch [CVE-2023-2603] surfaced in the runtime image's libcap library. Finally, the release contains a backported fix for service discovery on endpoints that use hostPorts which could potentially disrupt connections on pod restarts. * Control Plane * Changed how hostPort lookups are handled in the destination service. Previously, when doing service discovery for an endpoint bound on a hostPort, the destination service would return the corresponding pod IP. On pod restart, this could lead to loss of connectivity on the client's side. The destination service now always returns host IPs for service discovery on an endpoint that uses hostPorts [#11328] * Proxy * Addressed security vulnerability [RUSTSEC-2023-0052] [#11389] * CNI * Addressed security vulnerability [CVE-2023-2603] in proxy-init and CNI plugin [#11348] [#11328]: #11328 [#11348]: #11348 [#11389]: #11389 [RUSTSEC-2023-0052]: https://rustsec.org/advisories/RUSTSEC-2023-0052.html [CVE-2023-2603]: GHSA-wp54-pwvg-rqq5 Signed-off-by: Matei David <[email protected]>
Signed-off-by: Matei David <[email protected]>
alpeb
reviewed
Sep 20, 2023
alpeb
approved these changes
Sep 20, 2023
Signed-off-by: Matei David <[email protected]>
Signed-off-by: Matei David <[email protected]>
hawkw
approved these changes
Sep 20, 2023
Co-authored-by: Eliza Weisman <[email protected]>
This branch cherry-picks #2472 onto `release/v2.203`. Currently, the proxy [depends on an outdated version of `rustls`][1], v0.20.8. The `rustls` dependency is via our dependency on `tokio-rustls` v0.23.4; we don't have a direct `rustls` dependency, in order to ensure that the version of `rustls` is always the same version as used by `tokio-rustls`. `rustls` also has a dependency on `webpki`, and v0.20.x of `rustls` uses the original `webpki` crate, rather than the `rustls-webpki` crate. So, unfortunately, because we have a transitive dep on `webpki` via `rustls`, PR linkerd/linkerd2-proxy#2465 did not remove _all_ `webpki` deps from our dependency tree, only the direct dependency. This branch updates to `rustls` v0.21.x, which depends on `rustls-webpki` rather than `webpki`, removing the `webpki` dependency. This is accomplished by updating `tokio-rustls` to v0.24.x, implicitly updating the transitive `rustls` dep. In order to update to the semver-incompatible version of `rustls`, it was necessary to modify our code in order to track some breaking API changes. I've also added a `cargo-deny` ban for `webpki` to our `deny.toml`, to ensure that we always use the actively-maintained `rustls-webpki` crate rather than `webpki` classic. Since peer certificate validation is performed through `rustls` rather than through the direct `rustls-webpki` dependency, this should hopefully resolve issues with issuer certs that contain name constraints --- these were not fixed by linkerd/linkerd2-proxy#2465, because the failure with certs containing name constraints occurred inside of the *`webpki` version depended on by `rustls`*, rather than inside of the proxy's direct dep. See [this comment][2] for details. In addition, it was necessary to update `rustls-webpki` to v0.101.6, since v0.101.5 was yanked due to an accidental API breaking change. [1]: https://github.com/linkerd/linkerd2-proxy/blob/8afc72258b8ced868fbd0bde0235955c0adf4ccd/Cargo.lock#L2450-L2460C2 [2]: #9299 (comment) --- 0e843c9f meshtls: update to `rustls` v0.21.7 (linkerd/linkerd2-proxy#2473) Signed-off-by: Eliza Weisman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
stable-2.13.7
This stable releases addresses backports two fixes that address security
vulnerabilities. The proxy's dependency on the webpki library has been updated
to patch RUSTSEC-2023-0052, a potential CPU usage denial-of-service attack
when accepting a TLS handshake from an untrusted peer. In addition, the CNI and
proxy-init images have been updated to patch CVE-2023-2603 surfaced in the
runtime image's libcap library. Finally, the release contains a backported fix
for service discovery on endpoints that use hostPorts which could potentially
disrupt connections on pod restarts.
Control Plane
Previously, when doing service discovery for an endpoint bound on a
hostPort, the destination service would return the corresponding pod IP. On
pod restart, this could lead to loss of connectivity on the client's side.
The destination service now always returns host IPs for service discovery
on an endpoint that uses hostPorts #11328
Proxy
CNI
plugin #11348