Add pod2pod strict mode for WireGuard

[3u13r]

When pod2pod encryption is enabled, there is a slight time window, where one pod may send unencrypted data to another one. This happens when a new pod is created but the information of the new endpoint has not propagated to the other nodes.

To prevent this from happening, we block all unencrypted pod2pod traffic. This is done via a filter in the datapath. The filter is configured at the same time the datapth is set up, sine we cannot rely on data which is only eventually updated at runtime.
The filter drops any unencrypted tcp/udp egress traffic which originates from and is sent to the PodCIDR and also leaves the node.

Signed-off-by: Benedict Schlueter bs@edgeless.systems
Signed-off-by: Leonard Cohnen lc@edgeless.systems

Please ensure your pull request adheres to the following guidelines:

• For first time contributors, read Submitting a pull request
• All code is covered by unit and/or runtime tests where feasible.
• All commits contain a well written commit description including a title,
  description and a Fixes: #XXX line if the commit addresses a particular
  GitHub issue.
• If your commit description contains a Fixes: <commit-id> tag, then
  please add the commit author[s] as reviewer[s] to this issue.
• All commits are signed off. See the section Developer’s Certificate of Origin
• Provide a title or release-note blurb suitable for the release notes.
• Thanks for contributing!

Add strict mode for WireGuard Pod2Pod encryption

[maintainer-s-little-helper]

Commit 690e4daeb0252ee5a248889db024d3fbfb7210a4 does not contain "Signed-off-by".

Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin

[gandro]

Thanks a lot for this contribution. I focused on the agent side of things only, few comments.

[gandro]

Thanks!

[3u13r]

Thanks for running the tests. I hope I fixed all of the linting errors. I will try to investigate the other errors as soon as they arise.

[brb]

The CI failure looks legit. The IPsec tests, which are executed after the newly added WG tests, started to fail. In particular, the connectivity between Pods:

time="2023-06-06T17:50:58Z" level=debug msg="running local command: kubectl exec -n 202306061750k8sdatapathconfigtransparentencryptiondirectrouting testclient-7jrvs -- ping -W 5 -c 5 10.0.0.254"
time="2023-06-06T17:51:07Z" level=error msg="Error executing local command 'kubectl exec -n 202306061750k8sdatapathconfigtransparentencryptiondirectrouting testclient-7jrvs -- ping -W 5 -c 5 10.0.0.254'" error="exit status 1"
time="2023-06-06T17:51:07Z" level=error msg="Error executing local command 'kubectl exec -n 202306061750k8sdatapathconfigtransparentencryptiondirectrouting testclient-7jrvs -- ping -W 5 -c 5 10.0.0.254'" error="exit status 1"
cmd: "kubectl exec -n 202306061750k8sdatapathconfigtransparentencryptiondirectrouting testclient-7jrvs -- ping -W 5 -c 5 10.0.0.254" exitCode: 1 duration: 9.189357468s stdout:
PING 10.0.0.254 (10.0.0.254) 56(84) bytes of data.

I think we are hitting some form of #14959 with the CI

@3u13r Did you check cilium-agent logs to see whether they hit the same symptoms?

[3u13r]

The CI failure looks legit. The IPsec tests, which are executed after the newly added WG tests, started to fail. In particular, the connectivity between Pods:

time="2023-06-06T17:50:58Z" level=debug msg="running local command: kubectl exec -n 202306061750k8sdatapathconfigtransparentencryptiondirectrouting testclient-7jrvs -- ping -W 5 -c 5 10.0.0.254"
time="2023-06-06T17:51:07Z" level=error msg="Error executing local command 'kubectl exec -n 202306061750k8sdatapathconfigtransparentencryptiondirectrouting testclient-7jrvs -- ping -W 5 -c 5 10.0.0.254'" error="exit status 1"
time="2023-06-06T17:51:07Z" level=error msg="Error executing local command 'kubectl exec -n 202306061750k8sdatapathconfigtransparentencryptiondirectrouting testclient-7jrvs -- ping -W 5 -c 5 10.0.0.254'" error="exit status 1"
cmd: "kubectl exec -n 202306061750k8sdatapathconfigtransparentencryptiondirectrouting testclient-7jrvs -- ping -W 5 -c 5 10.0.0.254" exitCode: 1 duration: 9.189357468s stdout:
PING 10.0.0.254 (10.0.0.254) 56(84) bytes of data.

I think we are hitting some form of #14959 with the CI

@3u13r Did you check cilium-agent logs to see whether they hit the same symptoms?

As far as I can tell, the actual strict mode test are skipped in all 3 failed CI runs, correct? When my interpretation is that it's unlikely the strict mode test itself but the only other line that has changed in the tests i.e. the deletion of the ciliumnode resource.

[brb]

kubectl.DeleteResource("ciliumnode", "--all --wait")

Do we actually need those?

[3u13r]

kubectl.DeleteResource("ciliumnode", "--all --wait")

Do we actually need those?

Yes, we need to delete the ciliumnode resouce in order to change the PodCIDR during the strict mode tests. We basically need to clean up the allocated PodCIDR for each node after each strict mode test.
Moving the clean-up to only the strict mode tests itself could theoretically be possible though.

[brb]

Moving the clean-up to only the strict mode tests itself could theoretically be possible though.

Yep, but that would be a ticking bomb, as WG and IPsec tests might eventually end up running in the same job. Anyway, if the transition of the tests from the Ginkgo to ci-e2e / BPF unit tests (I think both can be rewritten into the BPF unit tests) happens soon, then ACK this approach.

[brb]

@3u13r could you do the suggested change (delete ciliumnode obj only in the strict wg tests)? The feature freeze for v1.14 is next Fri (16th June). It would be nice to get this feature merged before that date.

[joestringer]

Due to changes in CI, this will need rebasing to get CI to pass. From Martynas' last comment it looks like there's feedback remaining to address, but otherwise this seems close. We've initiated the feature freeze for v1.14 now so it'll miss that release series, but please do fix up the PR, we should be able to push this forward towards merging in a week or two once we've completed the branching process. Thanks for your continued interest in contributing to Cilium :-)

[3u13r]

Sadly, I've been sick over the past week and the obvious changes first didn't work. With the current version I'm able to execute the K8sDatapath tests on netnext (executing the strict mode tests) and without netnext (executing the direct routing ipsec test).
Currently not sure about the failing/aborting test K8sUpstreamNetConformance / kubernetes-e2e-net-conformance (ipv4). This test seems to be successful on other branches.

[brb]

/test

[ldelossa]

@3u13r If you'd like to push this PR forward, can you please rebase and push? The original base this PR is one has an issue with tests. This will be fixed with a rebase.

[gandro]

/test

[gandro]

Glad to see this finally merged 🎉

[3u13r]

Yay 🥳. Thanks a lot for the feedback and discussions from everyone! I'm excited that the first step is merged. Next tasks include IPv6 support, migrating the tests, node-to-node strict mode, ...