Conversation
1 similar comment
Member
Author
|
test-net-next |
Member
Author
|
test-me-please |
This extends the cilium-operator to allocate Wireguard IPs for each Cilium node from a user-defined subnet. Co-authored-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Martynas Pumputis <m@lambda.lt>
6452726 to
13ee10a
Compare
This commit adds support in the cilium-agent for configuring the local Wireguard device and establishing the tunnel to remote peers. This is implemented by watching for changes to the local and remote node objects. Wiregurad traffic to remote nodes is redirected by the ip route based on the MARK_MAGIC_ENCRYPT mark. Co-authored-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Martynas Pumputis <m@lambda.lt>
In this initial version, Wireguard cannot be configured in a more fine-grained manner. Follow-up work will likely add more knobs to the Helm chart to configure additional parameters. Co-authored-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Martynas Pumputis <m@lambda.lt>
The test is checking whether KPR is wired up properly when Wireguard is enabled, i.e. whether a NodePort BPF requests when a backend is on a remote node are forwarded over the wireguard tunnel. The log-gatherer image vsn bump is to be able to run tcpdump from it. Co-authored-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Sebastian Wicki <sebastian@isovalent.com> Signed-off-by: Martynas Pumputis <m@lambda.lt>
Member
Author
|
test-me-please |
Member
Author
|
@tklauser @christarazi @kkourt @joestringer @borkmann @rolinh @nathanjsweet Thanks for the reviews! I think all your feedback has been addressed. |
Member
Author
|
test-4.9 |
2 similar comments
Member
Author
|
test-4.9 |
Member
Author
|
test-4.9 |
Member
Author
|
The 4.9 CI failed with the same failure (unrelated to this PR) as the 4.9 master CI is currently failing (most likely #15487 might resolve the failure). All comments have been addressed and got ACK from a majority of the reviewers. Marking as |
youssefazrak
added a commit
to youssefazrak/cilium
that referenced
this pull request
Apr 9, 2021
This PR is to add the Wireguard support to the Helm charts. Following comment from PR cilium#15383 some refactoring has been done for the encryption part: we are now having to subchoices: IPSec or Wireguard for the encryption. Fixes: cilium#15483 Signed-off-by: Youssef Azrak <yazrak.tech@gmail.com>
This was referenced Apr 28, 2021
This was referenced Feb 27, 2026
This file contains hidden or 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
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.
This PR adds a native Wireguard support. Currently, the feature is restricted to Kubernetes and ClusterPool (with single podCIDR per node and IP family) IPAM, and works in the direct routing mode only (the tunneling mode is going to be supported in the future).
The feature consists of two major components -
pkg/wireguard/agent(which is run by cilium-agent) andpkg/wireguard/operator(run by a cilium-operator leader).At the high level, we create a wireguard tunnel device (
cilium_wg0) on each node, and set an IP from a dedicated subnet (in the code we call it as a wireguard subnet). Next, we generate a private key, and announce to remote nodes its public key via the CiliumNode object annotation. In addition, we use the same object to announce the wireguard tunnel IP, podCIDR. Finally, when the agent receives a remote CiliumNode object, it sets up the wireguard tunnel to the peer by using the nodeIP as wireguard endpoint address, the wireguard tunnel IP + podCIDR as allowed-ips, and the public key.Currently, we encrypt the following packets:
Both types of packets are marked with
MARK_MAGIC_ENCRYPTwhich is used by the following IP rule and route:Steering the packet to the
cilium_wg0device makes Wireguard to encrypt it. Note that there is no need to specify podCIDR => nodeIP routes, as Wireguard is able to derive a destination node by consulting the allowed-ips list which the agent configures.The operator is responsible for allocating wireguard tunnel IPs and setting them in CiliumNode objects. While, the agent is responsible for configuring the tunnel device, adding peers and direct routes.
An issue to track the follow-ups: #15462.
Co-developed with @gandro.
Fix #7519.