This bug was initially created as a copy of Bug #1943175 I am copying this bug to isolate SSH issue out of the other bug. Version: 4.7.2, also 4.6.something Platform: azure Please specify: * IPI What happened? Customer reports unable to install IPI PRIVATE OpenShift cluster in Azure. This previously worked, but when certain policies were applied to the customer's Azure account, it stopped working. The installer breaks on: 1. Unable to create network rule to allow SSH in. - "policyDefinition":{"name":"SSH access from the Internet should be blocked with Deny... What did you expect to happen? Installer completes successfully. How to reproduce it (as minimally and precisely as possible)? openshift-install using attached instsll-conmfig.yaml Anything else we need to know? - Installer log output attached - This is a private cluster, so we shouldn't be failing on the SSH probe.
Hello Christopher, When deploying a cluster with the IPI on Azure, a temporary NSG rule is created to allow SSH to the bootstrap node. When you create a private cluster, the rule still exists, but you can't reach the bootstrap from the Internet (even when using the default configuration of "outboundType: Loadbalancer", as only Outbound NAT is enabled). The temporary NSG rule and the Bootstrap machine are destroyed as soon the Bootstrap process is finished. Because no port is exposed to the Internet with a private cluster, you can only SSH to the bootstrap from the internal network. I believe the reason your policy is flagging this is because the temporary NSG rule uses "Any" as the source. Thank you for the feedback, I will investigate how we can improve that NSG rule on private clusters.
My customer made the following suggestion: > As a bug fix would it be possible for the NSG rule to set the source as the VNET since the VNET name is already provided during private cluster installs? In that case, I suspect instead of being "Any", source as VNET wouldn't trigger at least that customer rule. Something to consider? Thanks!
(In reply to Christopher Wawak from comment #4) > My customer made the following suggestion: > > > As a bug fix would it be possible for the NSG rule to set the source as the VNET since the VNET name is already provided during private cluster installs? > > In that case, I suspect instead of being "Any", source as VNET wouldn't > trigger at least that customer rule. Something to consider? Thanks! Hello Christopher, Thank you for the suggestion. The intended design for private clusters regarding ssh access to the bootstrap node is to only be able ssh to the bootstrap on the local network where it is deployed, which is what we're targeting on this bugzilla.
I got an ipi private cluster up with bootstrap. There is no public ip address for the bootstrap. Is there somewhere else I should check? Thanks.
(In reply to To Hung Sze from comment #8) > I got an ipi private cluster up with bootstrap. > There is no public ip address for the bootstrap. > Is there somewhere else I should check? > Thanks. The expected behavior of this bug fix is that when you create a private cluster on Azure, the "bootstrap_ssh_in" NSG rule will not exist. That's what should be verified. Before the bug fix, this rule still existed on private clusters until the bootstrap was destroyed. It only affects the NSG rule (which would help with the security policy issue the user was running into). There was already no possible way to access SSH from the Internet on a IPI Azure private cluster.
I confirm, for internal cluster on Az, with 4.7, there is a rule that allows ssh Priority Name Port Protocol Source Destination Action 103 bootstrap_ssh_in 22 Tcp Any Any Allow I can ssh into the bootstrap that has an external IP address via tszeaz051121b-prxnl-bootstrap-pip-v4. with 4.8, there is no such rule / external IP address. Marking as verified.
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 (Moderate: OpenShift Container Platform 4.8.2 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-2021:2438