Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-71133

allowedCIDRBlocks removed should also remove the LoadBalancerSourceRanges for the external router LoadBalancer service

    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • Rejected
    • None
    • In Progress
    • Bug Fix
    • Hide
      Before this update, when a HyperShift `HostedCluster` used external Domain Name Service (DNS) domains was updated to remove existing `allowedCIDRBlocks`, the external router `LoadBalancer` service was not updated to reflect this change. This resulted in external clients being able to access the kube-apiserver from any IP address, effectively bypassing the configured Classless Inter-Domain Routing (CIDR) restrictions. With this release, the `LoadBalancerSourceRanges` configuration is not removed from the external kube-apiserver service when `allowedCIDRBlocks` is removed from the `HostedCluster` ensuring consistent security across both internal and external traffic. (link:https://issues.redhat.com/browse/OCPBUGS-71133[OCPBUGS-71133])
      Show
      Before this update, when a HyperShift `HostedCluster` used external Domain Name Service (DNS) domains was updated to remove existing `allowedCIDRBlocks`, the external router `LoadBalancer` service was not updated to reflect this change. This resulted in external clients being able to access the kube-apiserver from any IP address, effectively bypassing the configured Classless Inter-Domain Routing (CIDR) restrictions. With this release, the `LoadBalancerSourceRanges` configuration is not removed from the external kube-apiserver service when `allowedCIDRBlocks` is removed from the `HostedCluster` ensuring consistent security across both internal and external traffic. (link: https://issues.redhat.com/browse/OCPBUGS-71133 [ OCPBUGS-71133 ])
    • None
    • None
    • None
    • None

      This is a clone of issue OCPBUGS-69761. The following is the description of the original issue:

      Description of problem:

      When HostedCluster is configured with external DNS domains , the `allowedCIDRBlocks` configuration in `spec.networking.apiServer.allowedCIDRBlocks` removed. The CIDR restrictions are still applied to external traffic flows through the unrestricted router LoadBalancer service.

      Version-Release number of selected component (if applicable):

          HyperShift 4.21

      How reproducible:

          Always

      Steps to Reproduce:

      1. Create a HostedCluster with External DNS Domain on AWS platform
      2. Set `spec.platform.aws.endpointAccess` to `PublicAndPrivate`
      3. Configure `spec.networking.apiServer.allowedCIDRBlocks` with restricted CIDR ranges:
         ```yaml
         spec:
           networking:
             apiServer:
               allowedCIDRBlocks:
                 - "100.48.157.95/32"
                 - "54.237.188.126/32"
      ...
         ```
      4. Deploy the cluster and wait for external router service to be created
      5. Remove the `spec.networking.apiServer.allowedCIDRBlocks`;

      Actual results:

      - External router LoadBalancer service still have `LoadBalancerSourceRanges` field configured : 
      
      
      oc get hc 42bf4c7dc31c50417e48 -o=jsonpath={.spec.networking} |jq
      {
        "clusterNetwork": [
          {
            "cidr": "10.132.0.0/14"
          }
        ],
        "machineNetwork": [
          {
            "cidr": "10.0.0.0/16"
          }
        ],
        "networkType": "OVNKubernetes",
        "serviceNetwork": [
          {
            "cidr": "172.31.0.0/16"
          }
        ]
      }
      
      
      
      oc get svc router -n clusters-42bf4c7dc31c50417e48 -o jsonpath='{.spec.loadBalancerSourceRanges}' |jq
      [
        "100.48.157.95/32",
        "54.237.188.126/32",
        "100.49.106.204/32"
      ]
       

      Expected results:

      - External router LoadBalancer service should remove `LoadBalancerSourceRanges` configured 

      Additional info:

       

              rh-ee-mraee Mulham Raee
              yinzhou@redhat.com Ying Zhou
              Ying Zhou
              None
              Ying Zhou Ying Zhou
              None
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated: