A pod could put any source MAC or address on the wire: weave has no layer-2
anti-spoofing, so a pod with NET_RAW could pose as another pod or as a node's
bridge, on its own node (local bridging never reaches the router) and, through
weave, on others. That undercut every rule that trusts a source MAC or address,
including the egress holder's check of which node a tunnel packet came from.
The CNI plugin now locks the host side of each pod's veth with tc ingress
filters: IPv4 from the pod's MAC and address, ARP speaking for exactly those
(or probing from 0.0.0.0) pass; everything else is dropped before the bridge
sees it. The u32 keys follow iproute2's layout for "ether src" (-8, -4) and
"ip src" (12). ADD fails if the port cannot be locked, so an unlocked pod never
starts. The filters go away with the veth.
Pods attached before this plugin get locked by weave-init: "weaveutil
lock-ports" walks libcni's result cache (each attachment's netns, interface and
address) and locks their ports, leaving locked ones alone. weave-init mounts
the cache and /var/run/netns read-only for it.
TestPortLockInKernel (root) builds a bridge and two pods in throwaway
namespaces and checks what reaches the other pod; reweave/test/portlock runs
the same against a live cluster, across nodes, after checking every port is
locked.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UHXzGrsxfkGk8LmwrBbHNZ
* Module name changed to `github.com/rajch/weave`
* Added environment variable `CHECKPOINT_DISABLE=1` to default manifests, to bypass weaveworks telemetry
We don't want everyone that uses the `net` package to get a transitive
dependency on the Kubernetes APIs, so have it define the `UID` type.
Conceptually this is a simple change because `UID` is a `string`, but
unfortunately it is used in a lot of places.
- Instead of EnsureBridge
- Adds ipset.ExistEntry method
- Refactor ipset method names Exist <-> EntryExists
- Turn on iptable-refresh by default (10s)
- Adds a test that checks iptables are refreshed, check EXPOSE recovers
Only block the specific port Weave Net is listening on.
Add a comment so users know what the rule is for.
Remove the rule added in v2.6.3 because it was too coarse.
We expect the loopback address 127.0.0.1 to be accessible only from
the local host.
We need to allow RELATED,ESTABLISHED traffic which may be the return
path of a Kubernetes HostPort.
Added a check to make sure the xfrm policy has not yet been updated to
a new spi. The ipsec mutex is held at this point so nothing else should
be modifying this policy.
Prior "bridge: Change local fdb entries whenever mac address of bridge device changes" [1],
FDB entry for a bridge was not inserted when creating the bridge and it could
only be inserted when a hw address of the bridge was changed. Therefore, on
an older than the 3.14 kernel containers were not able to reach
the "weave" bridge w/o setting the promiscuous mode on.
This should have hit hard Kubernetes users as the weave bridge in their
case is used as a default gateway, and thus it works only after manually
enabling the promiscuous mode.
Additionally, w/o the promiscuous mode a packet sent from a container and
destined to the gateway is flooded on all ports, so it can reach
the "datapath" device resulting in the "Vetoed installation of hairpin flow" error.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4b816d8ba1c1917842dc3de97cbf8ef116e043e
is found to be in DOWN state
Fixes#3133 Do something more useful when the weave bridge is DOWN
On Weave restart there is already logic in place to create the bridge interface
and bring it up, this fix only monotors the weave bridge interface and logs error if
it is in DOWN state
Egress does not work in the legacy netpol mode, so in the legacy case
we don't have to create the egress traffic steering rules. Otherwise,
some traffic will be blocked.
We need two rules:
* `-A INPUT -i weave -j WEAVE-NPC-EGRESS`: applies to packets destined
to a local node.
* `-A FORWARD -i weave -j WEAVE-NPC-EGRESS`: the rest. It can match
an ingress packet.
As ipset.New(...) can be called by two processes (weaver and weave-npc)
at the same time, there is a possibility for a race when they both
check the comment support. To prevent the race, we append a random
nonce to the test ipset name.
- Track only local changes.
- Add comment to the iptables rule which prevents SNAT'ing.
- Rename the ipset to weaver-no-masq-local to prevent NPC from destroying it.
- Fix comment about create/flush WEAVE-EXPOSE.
- Add comment about reexpose being no-op if bridge hasn't been exposed.
- Add comment that the feature is not only for Kubernetes.
- Reuse the ipset instance.
This ensures that all exposing-related iptables rules are created.
As we do the re-expose, we need to clear the WEAVE-EXPOSE chain
if such exists. Thus, we use ClearChain instead of NewChain to
create the chain.
Make the rule creation to use the same mechanism (via ensureRules)
as other rules from filter/FORWARD. Otherwise, the rule is preceded
by "-j WEAVE-EXPOSE" rule which can break the subnet isolation.
levaliciousandClaude Opus 5.5