Skip to content

[BUG] [CNI v0.3.0] master key in CNI config seemingly not used anywhere. #100

@aznashwan

Description

@aznashwan

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:

  1. Install the plugins and any required deps like runhcs for running a full container.
  2. Use a functional CNI config (e.g. the example nat network config in this repo)
  3. add/modify a top-level JSON config key named master to any random string which isn't an interface name on the host.
  4. 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)

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions