fix(cni-plugin): append inbound skip ports instead of replacing #518
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.
Fixes linkerd/linkerd2#13976
When the Linkerd CNI-plugin acts on a pod with a
config.linkerd.io/skip-inbound-ports
annotation, it replaces the inbound skip ports that the CNI-plugin was configured with instead of adding to them. The CNI-plugin is configured with the Linkerd proxy's admin and tap ports as skip inbound ports. Therefore, on any pod with theconfig.linkerd.io/skip-inbound-ports
annotation, the admin and tap ports will no longer be skipped by the iptables redirect rules, making these proxy ports inaccessible and causing tap and promethus scraping to no longer function.Instead of replacing, we append the ports specified in
config.linkerd.io/skip-inbound-ports
to the inbound skip ports. This allows the admin and tap ports to continue to skip iptables redirection and reach the proxy as desired.This matches the behavior of the linkerd-init container: https://github.com/linkerd/linkerd2/blob/main/charts/partials/templates/_proxy-init.tpl#L25
Tested manually on k3d with Calico and validating that tap works as expected on workloads with
config.linkerd.io/skip-inbound-ports
configured. Due to the architecture of the cni-plugin executable, it is not well set up to be tested automatically without further refactoring so we omit automated tests here.