Azure Public Cloud Update Infrastructure 101

The purpose of this post is to provide simple diagrams describing common issues Azure cloud users face when connecting to the Public Cloud Update Infrastructure with PAYG (Pay-As-You-Go) images and the solutions to these issues.

Instead of registering against the SUSE Customer Center like a traditional SUSE Linux Enterprise system, PAYG SLE systems are registered against the Public Cloud Update Infrastructure which is maintained by the SUSE Public Cloud Engineering team.

The Cloud Engineering team sets up access rules to secure and ease management of the Update Infrastructure servers. (Update Infrastructure is a general term which refers collectively to both Update and Region servers. More about these later.) These rules prevent certain access patterns to the infrastructure servers; Connections that originate from an IP address outside of the Azure ranges will fail. – Deprecated

Adding another layer of complexity to this issue, cloud users may “lock-down” their cloud instances and network with security rules or appliances in accordance with their organization’s security practices.  These security mechanisms have the potential to prevent connections to the Region and Update servers if they do not account for Update Infrastructure access.  The Update Infrastructure servers are not DNS resolvable, so adding a DNS hostname to a list of “allowed” hosts is not an option.

As a byproduct of the above mentioned access controls, the Azure and SUSE support teams regularly receive support cases from cloud users requesting help with Update Infrastructure connectivity issues.  Users often find themselves in this situation during initial deployment which is a critical time for any user as these connection problems may influence their decision to choose SUSE over another open-source alternative.

Before engaging Azure or SUSE support, check whether the problem is described by one of the scenarios outlined below.  If so, please read the scenario carefully, review your configuration, and attempt to resolve the issue on your own.  If you need further help or if the following scenarios do not describe your connection issue, please contact Azure or SUSE support.

SCENARIO 1

Problem: Cloud user creates a closed network by blocking network traffic to all but a select number of endpoints, causing a connection problem to the Update Infrastructure servers.

Solution: Understand which hosts need to be accessed for SLE instance registration and software updates; Create a new security rule to allow connections from the SLE instance to these specific hosts.

A Pay-As-You-Go SLE instance (client) must be able to connect to a Region (metadata) server during registration.  The instance must also connect to an Update server to complete registration and when installing new SUSE software or applying patches.  Connections to these servers over TCP port 80 and 443 must be allowed.

The IP addresses of the Region servers used by a SLE instance are located in the “regionsrv” parameter of the /etc/regionserverclnt.cfg file. During instance registration, the client asks one of these Region servers where it can find the Update servers for its region.  The Region server responds to the client with a list of Update servers within or near the instance’s local region.  The client then attempts a connection to one of these Update servers and registers against the first server to respond.  The IP address of the selected Update server is added to the client’s local /etc/hosts file under the name smt-azure.susecloud.net.

When the scope of the security issue is greater than a single instance, IPs for Region and Update servers can be ascertained with the pint[1] script which comes from the python3-susepubliccloudinfo package.

The output from the example below will display all the Azure Region and Update servers currently available.

sles-payg:~ # pint microsoft servers

For finer control, the output can be filtered to only list the Update servers in regions that will be in use.  The --region= flag can be used in conjunction with the --smt flag as a filter for this purpose;  Region servers, on the other hand, are region-agnostic and can be filtered with the --regionserver flag.

Any public cloud user security measures must allow connections from the SLE instance to the Region servers as well as its assigned Update server for repository access and instance registration to work correctly.

SCENARIO 2

######## SOLUTION DEPRECATED AS OF JUNE 2020 INFRASTRUCTURE REFRESH ########

IP-based access control no longer in use.  See here for details: https://www.suse.com/c/suse-update-infrastructure-access-through-the-data-center/

Problem: Cloud instance network traffic is routed through user’s on-premise datacenter before reaching the Update Infrastructure servers.  Region and Update servers do not respond to zypper or registration requests.

Cause: Azure Update Infrastructure servers reject connections from any host whose IP address is not within the specified range of Azure DC subnets published by Microsoft.[2]

Solution: Create a UDR (User Defined Route) for traffic destined for the Update Infrastructure servers to circumvent the externally-bound route.  From the perspective of the Region and Update server, a connection through a UDR should appear to come directly from the SLE instance.

If you are not sure whether your instance’s connection is using an valid IP address, you can find the egress IP of your instance’s connection to the Internet with this command.

sles-payg:~ # curl ifconfig.me

[1]: Riddle me this…

[2]: IP ranges currently in use by the Azure Cloud

Public (Global) Cloud: https://www.microsoft.com/en-us/download/confirmation.aspx?id=56519
China Cloud: https://www.microsoft.com/en-us/download/confirmation.aspx?id=57062
Germany Cloud: https://www.microsoft.com/en-us/download/confirmation.aspx?id=57064