-
Feature Request
-
Resolution: Unresolved
-
Undefined
-
None
-
openshift-4.14, openshift-4.15, openshift-4.16, openshift-4.17, openshift-4.18
-
None
-
False
-
None
-
False
-
Not Selected
-
-
-
-
1. Proposed title of this feature request
Validate IP Addresses/Subnets Against Defined Range in Network attach Definition Configuration during creation or edit
2. What is the nature and description of the request?
- In the NAD (Network Attach Definition) configuration, when adding IP addresses or subnets to the exclude list, the system does not validate whether the IP addresses are within the defined subnet range. This allows users to mistakenly add IPs or subnets outside the valid range, which can cause confusion and network misconfigurations.
- Steps to Reproduce:
- Set up a NAD configuration with the subnet range 192.169.1.0/24. Navigate to the section where you define the exclude list. Attempt to add an IP address or subnet to the exclude list, such as 192.169.0.80/31, which is outside the defined subnet 192.169.1.0/24. Save the configuration. Observe that no error is generated, and the configuration is saved successfully, even though the IP is outside the valid range.
- Expected Result: The system should validate that any IP address or subnet added to the exclude list is within the specified NAD range. In this case, attempting to add 192.169.0.80/31 should trigger an error, as it falls outside the 192.169.1.0/24 subnet. Actual Result: The system allows the addition of IP addresses or subnets outside the NAD's subnet range without generating any error or validation message.
- To extend this above scenario in my lab I have created below net-attach-def , where range_start and end is not part of the actual defined range. And Surprisingly using that nad pod has been successfully created with define gateway IP itself.
$ cat nad2.yaml apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: macvlan-net-attach2 spec: config: ' { "cniVersion": "0.3.1", "type": "macvlan", "Active": "bond0.28", "mode": "bridge", "ipam": { "type": "whereabouts", "range": "10.xx.28.0/24", "range_start": "10.xx.0.71", "range_end": "10.xx.0.76", "routes": [ { "dst": "10.xx.84.2/32" , "gw": "10.xx.28.1" } ], "gateway": "10.xx.28.1" } }' $ cat pod2.yaml apiVersion: v1 kind: Pod metadata: name: test annotations: k8s.v1.cni.cncf.io/networks: macvlan-net-attach2 spec: containers: - name: test-container image: gcr.io/google-samples/kubernetes-bootcamp:v1 command: ["/bin/sh"] args: ["-c", "sleep infinity"] $ oc rsh test # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0@if58: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default link/ether 0a:58:0a:83:00:23 brd ff:ff:ff:ff:ff:ff inet 10.131.0.35/23 brd 10.131.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::858:aff:fe83:23/64 scope link valid_lft forever preferred_lft forever 3: net1@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 92:ca:f4:2c:17:5c brd ff:ff:ff:ff:ff:ff inet 10.xx.28.1/24 brd 10.33.28.255 scope global net1 valid_lft forever preferred_lft forever inet6 2620:52:0:4ad0:90ca:f4ff:fe2c:175c/64 scope global mngtmpaddr dynamic valid_lft 2591952sec preferred_lft 604752sec inet6 fe80::90ca:f4ff:fe2c:175c/64 scope link valid_lft forever preferred_lft forever # ip r default via 10.131.0.1 dev eth0 10.xx.28.0/24 dev net1 proto kernel scope link src 10.xx.28.1 10.xx.84.2 via 10.33.28.1 dev net1 10.128.0.0/14 via 10.131.0.1 dev eth0 10.131.0.0/23 dev eth0 proto kernel scope link src 10.131.0.35 100.64.0.0/16 via 10.131.0.1 dev eth0 169.254.0.5 via 10.131.0.1 dev eth0 172.30.0.0/16 via 10.131.0.1 dev eth0
Expected Result: The system should validate that any IP address or subnet and its added content to the exclude list is within the specified NAD range. And can generate the warning during creation/modify time.
Actual Result: The system allows the addition of IP addresses or subnets outside the NAD's subnet range without generating any error or validation message.
3. Why does the customer need this? (List the business requirements here)
- This is a potential security risk that can lead to misconfigurations and access issues.
- Validation is required because, in the second scenario, the gateway IP is assigned to the pod itself, which can be dangerous and lead to an outage.
4. List any affected packages or components.
multus, net-attach-def, whereabouts, networking, telco
rhn-support-klakhwar
In order to speed up the processing of RFEs please ensure that a component is added to the RFE. Not adding a component may result in delays in processing the request.