Bump up opentelemetry to avoid scanner CVE warnings

[liu4480]

For CVE-2023-47108 and CVE-2023-45142.

These CVEs don't affect Antrea, including prior versions of Antrea.
This patch is only meant to avoid warnings from CVE scanners.

See also #5602

Signed-off-by: Bin Liu biliu@vmware.com

[liu4480]

/test-conformance
/test-e2e
/test-networkpolicy

[tnqn]

Is it typical to bump up indirect dependencies directly? Could it be overwriten when the direct dependency requiring it upgrades in the future?
cc @antoninbas

[antoninbas]

@tnqn This is fine. If a direct dependency upgrades and starts requiring a minimum version that > to the one we have in the go.mod, the indirect entry in our go.mod will be automatically updated to that new minimum version.

Typically the main concern is that you should not upgrade to a new major version, as that new major version may not be compatible with your direct dependency. The same concern can apply for pre-v1 minor version updates, if backward compatibility is broken. However, even though we have some major version updates here, it seems that everything still builds fine. In theory, it's possible to have some broken functionality, in case of a behavior change of the library. But we don't really leverage OTEL in the Antrea apiservers, and we don't provide a way to enable tracing:

In K8s v1.26, the APIServerTracing FeatureGate is Alpha, and disabled by default. This means that when we import version v0.26.4 of the apiserver module, the FeatureGate is automatically disabled, and it is not possible for users to enable it:
https://github.com/kubernetes/apiserver/blob/d3e415393e7e3642d9e6bb2a445385fd5e0e10bd/pkg/features/kube_features.go#L79

When we upgrade our K8s dependencies in the future, maybe it will make more sense to revert these changes and let K8s choose OTEL module versions.

[antoninbas]

This is fine by me. However, the commit message and PR description should make it clear that this is only to make CVE scanners happy, as these CVEs don't affect Antrea, including prior versions of Antrea. The current title, with the use of "fix", kind of implies that Antrea was affected by these CVEs. See #5602 (may be a good idea to reference the issue in the commit message as well).

We probably do not need to backport this to supported Antrea versions either. I know that K8s is not back-porting their PR (kubernetes/kubernetes#121338), as per their policy: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md

[antoninbas]

/test-all

[tnqn]

/skip-e2e

[tnqn]

@tnqn This is fine. If a direct dependency upgrades and starts requiring a minimum version that > to the one we have in the go.mod, the indirect entry in our go.mod will be automatically updated to that new minimum version.

Typically the main concern is that you should not upgrade to a new major version, as that new major version may not be compatible with your direct dependency. The same concern can apply for pre-v1 minor version updates, if backward compatibility is broken. However, even though we have some major version updates here, it seems that everything still builds fine. In theory, it's possible to have some broken functionality, in case of a behavior change of the library. But we don't really leverage OTEL in the Antrea apiservers, and we don't provide a way to enable tracing:

In K8s v1.26, the APIServerTracing FeatureGate is Alpha, and disabled by default. This means that when we import version v0.26.4 of the apiserver module, the FeatureGate is automatically disabled, and it is not possible for users to enable it:
https://github.com/kubernetes/apiserver/blob/d3e415393e7e3642d9e6bb2a445385fd5e0e10bd/pkg/features/kube_features.go#L79

When we upgrade our K8s dependencies in the future, maybe it will make more sense to revert these changes and let K8s choose OTEL module versions.

Got it, thanks for explanation.