Fix permission issue when copying cni plugins onto host path

[JohnJAS]

Fix permission issue when copying cni plugins onto host path.

The root cause is that the init container 'install-cni-binaries' didn't have securityContext.privileged settings inside the yaml like other init containers do. It leads to that it failed to copy cni binaries onto the hostpath which has no root permisison.

Fixes: #24889

Signed-off-by: Joseph Sheng jiajun.sheng@microfocus.com

[tommyp1ckles]

Think the change makes sense

CC @squeed I'm looking at your last change here: e1a4621. Was the intention that this works without the privileged init container?

[tommyp1ckles]

As well, thanks for the contribution!

[gandro]

Thanks!

[squeed]

I'm surprised this is necessary - @JohnJAS, what sort of issues did you have? Why was the privileged flag required?

[JohnJAS]

I'm surprised this is necessary - @JohnJAS, what sort of issues did you have? Why was the privileged flag required?

@squeed If cilium agent pod was started as root user, the root user inside container could not directly copy stuffs to the cni folder on hostpath which was not owned by root user. A root user inside a container is not equal to the root user on the host machine. It needs privileged in this case.
And another init contianer mount-cgroup has the same issue but it has the privileged flag to handle this case.

cilium/install/kubernetes/cilium/templates/cilium-agent/daemonset.yaml

Lines 469 to 471 in 5ca3696

	securityContext:
	{{- if .Values.securityContext.privileged }}
	privileged: true

IMO, if mount-cgroup container has the privileged flag, the same as install-cni-binaries .

Please refer to more details in #24889.

[squeed]

Huh. "works on my machine", but clearly this fixes a real issue. LGTM.

[gandro]

/test

[JohnJAS]

/test

[JohnJAS]

hi @gandro, i found that the CI test failed due to the connection timed out, but i think it was not related to the code change.
Err:1 http://azure.archive.ubuntu.com/ubuntu jammy-updates/main amd64 libnss-systemd amd64 249.11-0ubuntu3.9 Could not connect to azure.archive.ubuntu.com:80 (52.147.219.192), connection timed out
I commented \test but it didn't trigger another CI test. What else should I do for this PR?

[gandro]

I commented \test but it didn't trigger another CI test. What else should I do for this PR?

At the moment, only contributors with the commit bit can trigger the tests. Feel free to ping me or @cilium/tophat if you require the tests to be re-run.

i found that the CI test failed due to the connection timed out, but i think it was not related to the code change.

There are multiple different test failures. Many of them have Cilium in a CrashLoopBackoff. Just looking at "Suite-k8s-1.25.K8sDatapathConfig Transparent encryption DirectRouting Check connectivity with transparent encryption and direct routing with bpf_host", the reason for the crash is:

level=fatal msg="auto-direct-node-routes cannot be used with tunneling. Packets must be routed through the tunnel device." subsys=daemon

This is fortunately an unrelated issue:

• Slack thread in #development
• CI: New tests fail on all non-rebased pull requests #15474

We recently renamed that flag and the test driver code is using the new flag, where as you branch does not yet understand it. Could you rebase your PR on main to pull in the recent changes? After that, we can re-run CI again and triage the failures again.

[JohnJAS]

@gandro it's done, thanks for the reply ;-)

[gandro]

/test