Bug 2043804 - No way to verify if IPs with leading zeros are still valid in the apiserver
Summary: No way to verify if IPs with leading zeros are still valid in the apiserver
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: kube-apiserver
Version: 4.10
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.7.z
Assignee: Antonio Ojea
QA Contact: Rahul Gangwar
URL:
Whiteboard:
Depends On: 2043808
Blocks: 2043805
TreeView+ depends on / blocked
 
Reported: 2022-01-22 03:16 UTC by OpenShift BugZilla Robot
Modified: 2022-05-12 18:12 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-12 18:12:28 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift kubernetes pull 1234 0 None open [release-4.7][ART-3664] Bug 2043804: IPs with leading zeros are still valid in the apiserver 2022-04-05 16:04:17 UTC
Github openshift oauth-apiserver pull 76 0 None open [release-4.7][ART-3664] Bug 2043804: IPs with leading zeros are still valid in the apiserver 2022-04-05 16:10:30 UTC
Github openshift openshift-apiserver pull 287 0 None open [release-4.7][ART-3664] Bug 2043804: IPs with leading zeros are still valid in the apiserver 2022-04-05 16:12:29 UTC
Red Hat Product Errata RHBA-2022:1698 0 None None None 2022-05-12 18:12:37 UTC

Comment 1 Zimo Xiao 2022-04-11 06:29:00 UTC
This bug’s PR is dev-approved and not yet merged, so I’m following issue DPTP-660 to do the pre-merge verifying by using the bot to launch a cluster with the open PR. Here is the verification steps:

1. Launch cluster using cluster bot with still open but yet to approved PRs
$ oc get clusterversion
NAME      VERSION                                                  AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.7.0-0.ci.test-2022-04-11-012443-ci-ln-xtqrcb2-latest   True        False         6m34s   Cluster version is 4.7.0-0.ci.test-2022-04-11-012443-ci-ln-xtqrcb2-latest

2. Create service with leading zero IPs
$ cat ./service.json
{"kind": "Service", "apiVersion": "v1", "metadata": {"name": "test-service", "namespace": "openshift-apiserver"}, "spec": {"clusterIP": "172.30.1.02", "externalIP": "192.168.0.012", "externalName": "test-service-one", "ports": [{"port": 10000, "targetPort": 11000}], "selector": {"test": "data"}}}

$ oc create -f ./service.json
service/test-service created

Check if service is created with success
$ oc get svc test-service2 -n openshift-apiserver -o yaml
apiVersion: v1
kind: Service
…
  name: test-service
  namespace: openshift-apiserver
  resourceVersion: "36420"
  selfLink: /api/v1/namespaces/openshift-apiserver/services/test-service
  uid: c91237a8-b54e-4f2f-816f-ddf44e9bd58f
spec:
  clusterIP: 172.30.1.02
  clusterIPs:
  - 172.30.1.02

3. Create pod with leading zero IPs
$ cat ./file/pod.json    
{"kind": "Pod", "apiVersion": "v1", "metadata": {"name": "pod1", "namespace": "openshift-apiserver"}, "spec": {"containers": [{"image": "python", "name": "test-pod", "resources": {"limits": {"cpu": "1M"}, "requests": {"cpu": "1M"}}}]}, "status": {"podIP":"10.244.0.05","podIPs":[{"ip":"10.244.0.05"}]}}

$ oc create -f ./file/pod.json    
pod/pod1 created

Check if testing pod is created correctly
$ oc get po pod1 -n openshift-apiserver -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    openshift.io/scc: anyuid
  creationTimestamp: "2022-04-11T02:20:23Z"
…..
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      ….
      f:status:
        f:podIP: {}
        f:podIPs:
          .: {}
          k:{"ip":"10.244.0.05"}:
            .: {}
            f:ip: {}
    manager: kubectl-create
    operation: Update
    time: "2022-04-11T02:20:23Z"

As you can see, IPs with leading zeros are correctly parsed without disrupting user actions. So the bug is pre-merge verified. After the PR gets merged, the bug will be moved to VERIFIED by the bot automatically or, if not working, by me manually.

Comment 9 Rahul Gangwar 2022-04-29 11:53:38 UTC
oc get clusterversion      
NAME      VERSION                              AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.11.0-0.nightly-2022-04-27-234931   True        False         6h37m   Cluster version is 4.11.0-0.nightly-2022-04-27-234931
rahulgangwar@rgangwar-mac openshift-tests-private % vi service.json
{"kind": "Service", "apiVersion": "v1", "metadata": {"name": "test-service", "namespace": "openshift-apiserver"}, "spec": {"clusterIP": "172.30.1.02", "externalIP": "192.168.0.012", "externalName": "test-service-one", "ports": [{"port": 10000, "targetPort": 11000}], "selector": {"test": "data"}}}

rahulgangwar@rgangwar-mac openshift-tests-private % oc create -f ./service.json
service/test-service created


rahulgangwar@rgangwar-mac openshift-tests-private %  oc get svc test-service -n openshift-apiserver -o yaml 
apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2022-04-29T11:37:44Z"
  name: test-service
  namespace: openshift-apiserver
  resourceVersion: "165282"
  uid: a5aad80e-f931-48f0-9627-187b69e5156a
spec:
  clusterIP: 172.30.1.02
  clusterIPs:
  - 172.30.1.02
  externalName: test-service-one
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - port: 10000
    protocol: TCP
    targetPort: 11000
  selector:
    test: data
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

cat pod.json    
{"kind": "Pod", "apiVersion": "v1", "metadata": {"name": "pod1", "namespace": "openshift-apiserver"}, "spec": {"containers": [{"image": "python", "name": "test-pod", "resources": {"limits": {"cpu": "1M"}, "requests": {"cpu": "1M"}}}]}, "status": {"podIP":"10.244.0.05","podIPs":oc create -f pod.json 
pod/pod1 created
rahulgangwar@rgangwar-mac openshift-tests-private % oc get po pod1 -n openshift-apiserver -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    openshift.io/scc: anyuid
  creationTimestamp: "2022-04-29T11:39:14Z"
  name: pod1
  namespace: openshift-apiserver
  resourceVersion: "165838"
  uid: 29eb49ab-4509-43aa-8f62-7a81b778ea75
spec:
  containers:
  - image: python
    imagePullPolicy: Always
    name: test-pod
    resources:
      limits:
        cpu: 1M
      requests:
        cpu: 1M
    securityContext:
      capabilities:
        drop:
        - MKNOD
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-rxmxz
      readOnly: true
[{"ip":"10.244.0.05"}]}}

As you can see, IPs with leading zeros are correctly parsed without disrupting user actions.

Comment 13 errata-xmlrpc 2022-05-12 18:12:28 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (OpenShift Container Platform 4.7.50 bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:1698


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