Accessing IBM Cloud Satellite Services from a Restricted Client Network Using HTTP Proxies
Clients interested in consuming IBM Cloud Satellite Services can reside in a restricted network environment both from a IP connectivity and DNS resolution perspective. In these environments: clients often cannot resolve IBM Cloud Satellite specific domains including cluster ingress domains and location domains. Additionally: these clients do not have direct access to the networks running the IBM Cloud Satellite Services. In these environments: HTTP proxies can provide an access controlled way for clients from a restricted network to connect to the IBM Cloud Satellite Services. This guide walks through accessing the Openshift Console of a ROKS on Satellite cluster within a VPC to clients using Squid as the HTTP proxy.
We start with a IBM Cloud Satellite and ROKS on Satellite cluster deployed in a private VPC. The example environment details are shown below:
tylerlisowski$ ibmcloud sat hosts --location tyler-loc-useast
Retrieving hosts...
OK
Name ID State Status Zone Cluster Worker ID Worker IP
tyler-testtest-1 152f156d75c032fd4b05 assigned Ready us-east-1 infrastructure sat-tylertestt-f942e3a4fee94f29be06081424dad00c0a4e62ab 10.240.0.76
tyler-testtest-11 b9a5a03e7261221bf65a assigned Ready us-east-1 infrastructure sat-tylertestt-6909322966b8d8eb10fc45a0299852dead5a1591 10.240.0.21
tyler-testtest-12 41794a98a9b3db902c6d assigned Ready us-east-2 infrastructure sat-tylertestt-c29a0fff49a7d710fc943222513f490c11246c04 10.240.0.22
tyler-testtest-13 4dcc290c9dbed1ab4a3c assigned Ready us-east-3 infrastructure sat-tylertestt-a94a00c0088445306913c08aae2212b064fb3c22 10.240.0.23
tyler-testtest-2 787058c8d516a74131f7 assigned Ready us-east-3 infrastructure sat-tylertestt-d72e5734ed6199b4e0ff223c6335e349ea39226a 10.240.0.77
tyler-testtest-3 3d13d3e4aaea788ce3e7 assigned Ready us-east-2 infrastructure sat-tylertestt-84999d4c14c83044ea3b4e418e4badfd677b5f20 10.240.0.78
tyler-testtest-8 48d0ebbbdd4eb0b8a24c assigned Ready us-east-1 tyler-loc-useast-d-1 sat-tylertestt-6b232b18eb144361d0f27011b7f2eec52e43b802 10.240.0.19
tyler-testtest-9 1f199aacadbc702e36d8 assigned Ready us-east-1 tyler-loc-useast-d-1 sat-tylertestt-c50eabbf3519e3bed71206765a1a4784ac3c2d2e 10.240.0.20tylerlisowski$ ibmcloud cs cluster get --cluster tyler-loc-useast-d-1
Retrieving cluster tyler-loc-useast-d-1...
OKName: tyler-loc-useast-d-1
ID: cbqg0h3w0scd7l9mc6gg
State: normal
Status: All Workers Normal
Created: 2022-08-11 08:12:36 -0500 (3 weeks ago)
Pod Subnet: 172.30.0.0/16
Service Subnet: 172.21.0.0/16
Workers: 2
Worker Zones: us-east-1
Ingress Subdomain: tyler-loc-useast-d-1-80d128fecd199542426020c17e5e9430-0000.us-east.containers.appdomain.cloud
Public Service Endpoint URL: https://c-01.private.us-east.link.satellite.cloud.ibm.com:32915
Private Service Endpoint URL: https://t80bc734cb074c8b16595-6b64a6ccc9c596bf59a86625d8fa2202-ce00.us-east.satellite.appdomain.cloud:30617Master
Status: Ready (4 days ago)
State: deployed
Health: normal
Version: 4.11.0_1521_openshift
Location: tyler-loc-useast
URL: https://t80bc734cb074c8b16595-6b64a6ccc9c596bf59a86625d8fa2202-ce00.us-east.satellite.appdomain.cloud:30617
The infrastructure in this private VPC that make up the Satellite Location and run the Satellite Services are not accessible from my client network. This can be seen when I try to access the Openshift Console without any proxy configuration:
We will now proceed to provision and run an HTTP proxy using Squid. Squid will be ran on a machine that can be accessed by the clients in the restricted network and can send traffic to the infrastructure running the Satellite Services. Installing and configuring squid on a RHEL 8 machine is shown below:
With the proxy activated and in place: we can generate a proxy auto configuration file that can be used to configure a browser to send all traffic to the HTTP proxy. The file for my example environment is shown below:
The key piece to note is the IP address of the proxy (169.63.190.35) is accessible from my restricted client network. With this configuration in place: all client HTTP/HTTPS requests will be sent to the proxy. The proxy will handle resolving the DNS name in the request and ultimately proxying that connection to the appropriate backend. All that is required by the client is it must be able to resolve the DNS of the HTTP proxy machine(s) (if applicable) and have IP connectivity to the machine(s) running the proxy.
The proxy configuration can be loaded into Firefox using the preferences page:
With the configuration loaded and in place: we can now access the Openshift Console:
Additionally: we can also access the ROKS Apiserver with kubectl/oc using the HTTP proxy as well
Tylers-MacBook-Pro:~ tylerlisowski$ export HTTPS_PROXY="http://169.63.190.35:3128"
Tylers-MacBook-Pro:~ tylerlisowski$ bx cs cluster config --cluster tyler-loc-useast-d-1 --admin
OK
The configuration for tyler-loc-useast-d-1 was downloaded successfully.
Added context for tyler-loc-useast-d-1 to the current kubeconfig file.
You can now execute 'kubectl' commands against your cluster. For example, run 'kubectl get nodes'.
If you are accessing the cluster for the first time, 'kubectl' commands might fail for a few seconds while RBAC synchronizes.Tylers-MacBook-Pro:~ tylerlisowski$ kubectl get node
NAME STATUS ROLES AGE VERSION
tyler-testtest-8 Ready master,worker 3d18h v1.24.0+4f0dd4d
tyler-testtest-9 Ready master,worker 3d18h v1.24.0+4f0dd4d
Any HTTP/HTTPS services within the location can be accessed in a similar manner. This guide configured basic IP based access controls in squid but it did not configure any domain allowlisting from a squid perspective. Squid’s configuration can be consulted for more advanced configurations that introduce domain allowlisting.
