-
Notifications
You must be signed in to change notification settings - Fork 48
Description
Describe the bug
Most non-Flannel-based CNI config examples include a key named master
which contains the name of a host interface such as "Ethernet"
.
Although this may have been used at some point in the past, the CNI plugin code currently does NOT check/use this key in any way.
Looking through the main code (excluding the unit test code), the main place where the config is parsed is through wincni.ParseNetworkConfig, which returns a wincni.NetworkConfig
which doesn't load said argument at all.
FWIW I have run the containerd intergration test suite (uses the nat
plugin for tests) using a random interface name on my fork and all tests ran fine.
Additionally, my colleague @ionutbalutoiu has recently removed any interface renaming behavior on the Flannel-based CI and also confirmed that Flannel doesn't use said argument either.
To Reproduce
Steps to reproduce the behavior:
- Install the plugins and any required deps like
runhcs
for running a full container. - Use a functional CNI config (e.g. the example nat network config in this repo)
- add/modify a top-level JSON config key named
master
to any random string which isn't an interface name on the host. - observer that the plugins execute ADD/DEL commands just fine.
Expected behavior
For the value of the master
key to be used internally in some way, and setting it to a random non-existent interface name should have lead to the CNI plugins failing or at logging a warning about it.
CNI Version
Tried with CNI config version 0.2.0 and 0.3.0.
Additional context
There is a chance that the master
config param was once used in the past for automatically adding routes to the host interface by name for the HNS endpoint acting as the gateway on SDNBridge networks, similar to how the connectivity tests handle it?
There is also a chance that the example configs featuring the master
key were initially meant for a "higher-level" tool internal to Microsoft which used it, only to then later call the plugins in turn. (though I have no insider knowledge of such a tool)