Configuring IP Whitelisting for OpenStack Load Balancer using Horizon and CLI on Eumetsat Elasticity

This guide explains how to configure IP whitelisting (allowed_cidrs) on an existing OpenStack Load Balancer using Horizon and CLI commands. The configuration will limit access to your cluster through load balancer.

What We Are Going To Cover

  • Prepare Your Environment

  • Whitelist the load balancer via the CLI

Prerequisites

No. 1 Account

You need a Eumetsat Elasticity hosting account with access to the Horizon interface: https://horizon.cloudferro.com/auth/login/?next=/.

No. 2 List of IP addresses/ranges to whitelist

This is the list of IP addresses that you want the load balancer to be able to listen to.

In this article, we will use the following two addresses to whitelist:

  • 10.0.0.0/8

  • 10.95.255.0/24

No. 3 Python Octavia Client

To operate Load Balancers with CLI, the Python Octavia Client (python-octaviaclient) is required. It is a command-line client for the OpenStack Load Balancing service. Install the load-balancer (Octavia) plugin with the following command from the Terminal window, on Ubuntu 22.04:

pip install python-octaviaclient

Or, if you have virtualenvwrapper installed:

mkvirtualenv python-octaviaclient
pip install python-octaviaclient

Prepare Your Environment

First of all, you have to find id of your load balancer and its listener.

Horizon:

To find a load balancer id, go to Project >> Network >> Load Balancers and find that one which is associated with your cluster (its name will be with prefix of your cluster name).

../_images/whitelisting_again-1.png

Click on load balancer name (in this case lb-testing-ih347dstxyl2-api_lb_fixed-w2im3obvdv2p-loadbalancer_with_flavor-ykcmf6vvphld) then go to Listeners pane. There you will have a listener associated with that load balancer.

../_images/whitelisting_again-2.png

CLI

To use CLI to find the listener, you have to know the following two cluster parameters:

  • Stack ID

  • Cluster ID

You can find them from Horizon commands Container Infra –> Clusters and then click on the name of the cluster:

../_images/whitelisting-loadbalancer-4.png

At the bottom of the window, find the Stack ID:

../_images/whitelisting-loadbalancer-5.png

Now execute the commands:

openstack coe cluster show <your_cluster_id>  \
-f value -c stack_id \
<stack_id for example 12345678-1234-1234-1234-123456789011>

To find LB_ID

openstack stack resource list <your_stack_id> \
-n 5 -c resource_name -c physical_resource_id \
| grep loadbalancer_with_flavor \
| loadbalancer_with_flavor \
| <flavor_id for example 12345678-1234-1234-1234-123456789011>

With that information, now we can check our listener_id; it is to this component that we will attach the whitelist:

openstack loadbalancer \
show 2d6b335f-fb05-4496-8593-887f7e2c49cf \
-c listeners \
-f value \
<listener_id for example 12345678-1234-1234-1234-123456789011>

Whitelist the load balancer via the CLI

We now have the listener and the IP addresses which will be whitelisted. This is the command that will set up the whitelisting:

openstack loadbalancer listener set \
--allowed-cidr 10.0.0.0/8 \
--allowed-cidr 10.95.255.0/24 \
<listener_id for example 12345678-1234-1234-1234-123456789011>
../_images/whitelisting_again-3.png

State of Security: Before and After

Before implementing IP whitelisting, the load balancer accepts traffic from all sources. After completing the procedure:

  • Only specified IPs can access the load balancer.

  • Unauthorized access attempts are denied.

Verification Tools

Various tools can ensure the protection is installed and active:

livez

Kubernetes monitoring endpoint.

nmap

(free): For port scanning and access verification.

curl

(free): To confirm access control from specific IPs.

Wireshark

(free): For packet-level analysis.

Testing using curl and livez

Here is how we could test it:

curl -k https://<KUBE_API_IP>:6443/livez?verbose

That command assumes that you have

curl

installed and operational

<KUBE_API_IP>

which you can see through Horizon commands API Access –> View Credentials

livez

which is a piece of software which will show what happens with the load balancer.

This would be a typical response before changes:

curl -k https://<KUBE_API_IP>:6443/livez?verbose
[+]ping ok
[+]log ok
[+]etcd ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/priority-and-fairness-config-consumer ok
[+]poststarthook/priority-and-fairness-filter ok
[+]poststarthook/storage-object-count-tracker-hook ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/start-system-namespaces-controller ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/priority-and-fairness-config-producer ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-apiserver-identity-lease-controller ok
[+]poststarthook/start-deprecated-kube-apiserver-identity-lease-garbage-collector ok
[+]poststarthook/start-kube-apiserver-identity-lease-garbage-collector ok
[+]poststarthook/start-legacy-token-tracking-controller ok
[+]poststarthook/aggregator-reload-proxy-client-cert ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
[+]poststarthook/apiservice-openapiv3-controller ok
[+]poststarthook/apiservice-discovery-controller ok
livez check passed

And, this would be a typical response after the changes:

curl -k https://<KUBE_API_IP>:6443/livez?verbose -m 5
curl: (28) Connection timed out after 5000 milliseconds

Whitelisting prevents traffic from all IP addresses apart from those that are allowed by --allowed-cidr.

Testing with nmap

To test with nmap:

nmap -p <PORT> <LOAD_BALANCER_IP>

Testing with curl directly

To test with curl:

curl http://<LOAD_BALANCER_IP>

What To Do Next

You can wrap up this procedure with Terraform and apply to a larger number of load balancers. See Configuring IP Whitelisting for OpenStack Load Balancer using Terraform on Eumetsat Elasticity

Also, compare with Implementing IP Whitelisting for Load Balancers with Security Groups on Eumetsat Elasticity