Bug 2212143 - preserveDefaultVlan should be set to False to filter undesired VLAN tags
Summary: preserveDefaultVlan should be set to False to filter undesired VLAN tags
Keywords:
Status: POST
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: containernetworking-plugins
Version: 9.2
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jindrich Novy
QA Contact: Yuhui Jiang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-06-04 10:19 UTC by Yossi Segev
Modified: 2023-08-17 07:29 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github containernetworking cni.dev pull 119 0 None Merged Add preserveDefaultVlan parameter 2023-06-09 08:31:33 UTC
Red Hat Issue Tracker RHELPLAN-158910 0 None None None 2023-06-04 10:25:45 UTC

Description Yossi Segev 2023-06-04 10:19:25 UTC
Description of problem:
In addition to the fix for https://bugzilla.redhat.com/show_bug.cgi?id=2179333, the used should also explicitly set `preserveDefaultVlan`, which is default True, to False in the NetworkAttachmentDefinition.
This should be documented in https://github.com/containernetworking/cni.dev (in content/plugins/current/main/bridge.md).

Comment 6 Petr Horáček 2023-06-15 11:30:38 UTC
I know this request comes in quite late, but is there any chance we could change the default of the CNI instead of just documenting it? Having preserveDefaultVlan True by default is IMO unsafe and counterintuitive.

My worry is that today, users of the bridge CNI are requesting a VLAN with the expectation that their Pods will be fully isolated to this VLAN. That is however not not the case since by default their Pods would be also exposed to VLAN 1 which may contain sensitive management traffic. While this new preserveDefaultVlan attribute allows them to fix that gap in isolation, it is suboptimal since they need to change their existing configuration.

While theoretically there may have been users who relied on the VLAN 1 to be exposed in addition to the requested VLAN ID, I would argue that they would be the exception (if they exist at all).


Note You need to log in before you can comment on or make changes to this bug.