SUSE PAYG Repository Setup Helper

This tool will provide information needed to allow an instance access to the SUSE public cloud update infrastructure

Start by selecting the cloud service provider and region of instance

Allow outbound communication to region servers

Why

Region Servers are information servers. They provide update server IP addresses depending on the instance's region. They are a mandatory part of the infrastructure.

How

1. Open HTTPS TCP Port 443 to two or more of the following region server IPs:

Learn More But Not Required

Before an instance can get access to repositories, it needs to find out which RMT servers, a.k.a. update servers to use.

But even before this, the instance needs to know what location or region it's in. It finds this out by querying the instance metadata service which is managed and provided by the CSP. This metadata service is found at 169.254.169.254 on all the CSPs.

Once the instance knows its region, it will communicate this region to a region server. The region servers that need to be communicated with are already known to the instance. The IPs are found in the "regionsrv" variable in the /etc/regionserverclnt.cfg file.

The instance queries the region servers until one of them answers with the IP addresses of the update servers. The instance should now know the update server IPs for its region.

Multiple region servers are available for redundancy.

Allow outbound communication to RMT (update) servers

Why

Update Servers provide the actual software repositories for SUSE Linux Enterprise PAYG instances. At least three update servers serve a given region per cloud provider. They are a mandatory part of the infrastructure.

How

1. Open HTTPS TCP Port 443 to the following update server IPs:


2. On the instance, open the file /etc/regionserverclnt.cfg. and look for httpsOnly = true.
If httpsOnly = true, then you are finished with this step.

If httpsOnly = true is missing or httpsOnly = false then open HTTP TCP Port 80 to the following update server IPs:

Learn More But Not Required

Once an instance has the update server IP addresses, it will communicate with all of the update servers to see which responds first. The update server that responds first is selected, and a host record is added to /etc/hosts, resolving smt-<PROVIDER>.susecloud.net to the selected update server’s IP address. This record is added locally because it will not be publicly resolvable.

After the host record is added, the instance will import the certificate from the update server into /usr/share/pki/trust/anchors and then run update-ca-certificates. This certificate will then be used to create an encrypted session between the instance and the update server.

Finally, if all communication passes and there are no unexpected issues, the registration completes with all repositories being made available to the instance.

Proxy Server Considerations

Instances configured to utilize a proxy server or traverse firewalls, NAT gateways, proxies, security rules, Zscalar, or other security and network devices may run into problems.

The instance communicates with the region server (Step 1) using certificates local to the instance located in /var/lib/regionService/certs. This is when customers typically run into problems with a MITM (man-in-the-middle) proxy, Zscalar, or similar device. These MITM devices intercept the TLS traffic between the instance and the region server and instead utilize a trusted MITM certificate between the proxy and the instance. This MITM certificate is unknown to the region servers. As a result, the connection to the region server is terminated before the instance acquires the required information to continue the registration.

The instance communicates with the update server (Step 2) using certificates imported from the update server to /usr/share/pki/trust/anchors. This certificate will then be used to create an encrypted session between the instance and the update server. Once again, this is when customers run into problems with a MITM proxy or similar device. The certificate from the update servers cannot be intercepted and replaced or the session will fail.

The update infrastructure is designed using certificate pinning. This will cause problems with MITM devices that intercept the pinned certificates and replace them with their own. The MITM device will need to exempt the update infrastructure IPs from SSL inspection to prevent these problems.

To accommodate the SUSE public cloud update infrastructure:
1. Exempt all region server IPs obtained in Step 1 from SSL inspection.
2. Exempt all update servers IPs obtained in Step 2 from SSL inspection.
3. Exempt from SSL inspection

Metadata Server Considerations

The registration process all depends on the metadata server at 169.254.169.254 being available. This address should be excluded from being proxied.