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

Allow installer to use existing Azure NSG during OpenShift IPI install

    • No
    • False
    • Hide

      None

      Show
      None
    • Hide
      Previously, installing an Azure cluster into an existing Azure Virtual Network (VNet) might have failed because the installation program created a default network security group, which allowed traffic from `0.0.0.0`. The failure occurred when the existing VNet had the following rule enabled in the tenant: `Rule: Network Security Groups shall not allow rule with 0.0.0.0/Any Source/Destination IP Addresses - Custom Deny`. With this fix, the installation program no longer creates the default network security group when installing a cluster into an existing VNet, and the installation succeeds. (link:https://issues.redhat.com/browse/OCPBUGS-11796[*OCPBUGS-11796*])
      Show
      Previously, installing an Azure cluster into an existing Azure Virtual Network (VNet) might have failed because the installation program created a default network security group, which allowed traffic from `0.0.0.0`. The failure occurred when the existing VNet had the following rule enabled in the tenant: `Rule: Network Security Groups shall not allow rule with 0.0.0.0/Any Source/Destination IP Addresses - Custom Deny`. With this fix, the installation program no longer creates the default network security group when installing a cluster into an existing VNet, and the installation succeeds. (link: https://issues.redhat.com/browse/OCPBUGS-11796 [* OCPBUGS-11796 *])
    • Bug Fix
    • Done

      Description of problem:

      In an install where users bring their networks they also bring their own NSGs. However, the installer still creates NSG. In Azure environments using the rule [1] below, users are prohibited from installing cluster, as the apiserver_in rule has the rule set as 0.0.0.0[2]. Having a rule in place where the users could define this before install would allow them to set this connectivity without having the inbound access 
      
      
      
      [1] - Rule: Network Security Groups shall not allow rule with 0.0.0.0/Any Source/Destination IP Addresses - Custom Deny
      
      [2] - https://github.com/openshift/installer/blob/master/data/data/azure/vnet/nsg.tf#L31
      

            [OCPBUGS-11796] Allow installer to use existing Azure NSG during OpenShift IPI install

            Errata Tool added a comment -

            Since the problem described in this issue should be resolved in a recent advisory, it has been closed.

            For information on the advisory (Important: OpenShift Container Platform 4.14.0 bug fix and security 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/RHSA-2023:5006

            Errata Tool added a comment - Since the problem described in this issue should be resolved in a recent advisory, it has been closed. For information on the advisory (Important: OpenShift Container Platform 4.14.0 bug fix and security 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/RHSA-2023:5006

            Jinyun Ma added a comment -

            Tested again on 4.14.0-0.nightly-2023-06-29-065352, nsg rule "apiserver_in" is removed from nsg which installer created.

            $ az network nsg rule list --nsg-name jima11796-6kqsx-nsg -g jima11796-6kqsx-rg --query '[].name'
            [
              "a841757d108c2408191a4169a5c934bf-TCP-80-Internet",
              "a841757d108c2408191a4169a5c934bf-TCP-443-Internet"
            ] 

            Move bug to VERIFIED.

            Jinyun Ma added a comment - Tested again on 4.14.0-0.nightly-2023-06-29-065352, nsg rule "apiserver_in" is removed from nsg which installer created. $ az network nsg rule list --nsg-name jima11796-6kqsx-nsg -g jima11796-6kqsx-rg --query '[].name' [   "a841757d108c2408191a4169a5c934bf-TCP-80-Internet" ,   "a841757d108c2408191a4169a5c934bf-TCP-443-Internet" ] Move bug to VERIFIED.

            rh-ee-ssnyder I just confirmed with padillon and, unfortunately, we cannot skip the creation of the security group because the cloud provider requires a NSG. So if we simply skip creating the NSG we will have an issue (cloud provider will throw an error).

            Rafael Fonseca dos Santos added a comment - rh-ee-ssnyder I just confirmed with padillon and, unfortunately, we cannot skip the creation of the security group because the cloud provider requires a NSG . So if we simply skip creating the NSG we will have an issue (cloud provider will throw an error).

            I just wanted to follow up and see if this still progressing. The purpose of this originally was because if this rule is provided up front, it could make giving the service principal the below permissions not needed, which would allow for tighter security controls on the SP.

            • Microsoft.Network/networkSecurityGroups/securityRules/read
            • Microsoft.Network/networkSecurityGroups/securityRules/write

            I also see rh-ee-bbarbach mention skipping the creation of security group in the PR If we could skip both the rule creation and nsg creation (when provided up front) this could also allow us to remove this permission from the service principal to allow for tighter security.

            • Microsoft.Network/networkSecurityGroups/write

            Shane Snyder added a comment - I just wanted to follow up and see if this still progressing. The purpose of this originally was because if this rule is provided up front, it could make giving the service principal the below permissions not needed, which would allow for tighter security controls on the SP. Microsoft.Network/networkSecurityGroups/securityRules/read Microsoft.Network/networkSecurityGroups/securityRules/write I also see rh-ee-bbarbach mention skipping the creation of security group in the PR If we could skip both the rule creation and nsg creation (when provided up front) this could also allow us to remove this permission from the service principal to allow for tighter security. Microsoft.Network/networkSecurityGroups/write

            Jinyun Ma added a comment -

            rdossant  got it, thanks.
            Pre-merge testing passed on both IPI clusters w/o existing vnet, installation succeeded.

            Jinyun Ma added a comment - rdossant   got it, thanks. Pre-merge testing passed on both IPI clusters w/o existing vnet, installation succeeded.

            So even apiserver_in rule is there, should not impact users own NSG rules attached on their network, is it right?

            jinyunma I think so. But even if it's not actually used, its creation can trigger customer's policy rules.

            Rafael Fonseca dos Santos added a comment - So even apiserver_in rule is there, should not impact users own NSG rules attached on their network, is it right? jinyunma I think so. But even if it's not actually used, its creation can trigger customer's policy rules.

              rdossant Rafael Fonseca dos Santos
              rh-ee-ssnyder Shane Snyder
              Jinyun Ma Jinyun Ma
              Mike Pytlak Mike Pytlak (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: