Wdrażanie whitelistingu listy adresów IP dla load balancerów z grupami zabezpieczeń w NSIS Cloud
W tym artykule opisujemy, jak używać poleceń w Horizon, CLI i Terraform do zabezpieczania load balancerów dla klastrów Kubernetes w OpenStack poprzez implementację whitelistingu adresów IP.
Co zostanie omówione?
Wprowadzenie
Load balancery bez odpowiednich ograniczeń są podatne na nieautoryzowany dostęp. Wdrożenie białej listy adresów IP umożliwia dostęp do load balancera tylko określonym adresom IP. Użytkownik decyduje, z którego adresu IP można uzyskać dostęp do poszczególnych load balancerów i ogólnie do klastra Kubernetes.
Wymagania wstępne
Nr 1 Konto
Jest wymagane konto hostingowe NSIS z dostępem do interfejsu Horizon: https://horizon.cloudferro.com.
Nr 2 Lista adresów IP / zakresów adresów, które mają być umieszczone na białej liście
Jest to lista adresów IP, które mają być nasłuchiwane przez load balancer.
Nr 3 Wstępnie skonfigurowany load balancer
Za każdym razem, gdy w OpenStack tworzony jest klaster Kubernetes, automatycznie tworzone są odpowiednie load balancery.
Zobacz artykuł Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum.
Nr 4 Działające polecenie OpenStack
Jest to niezbędne dla procedur CLI.
Sprowadza się to do pozyskania odpowiedniego pliku RC z Horizon. Zobacz artykuł Jak korzystać z interfejsu wiersza poleceń dla klastrów Kubernetes w NSIS OpenStack Magnum
Nr 5 Klient Python Octavia
Do obsługi load balancerów za pomocą CLI wymagany jest klient Python Octavia (python-octaviaclient). Jest to klient wiersza poleceń dla usługi równoważenia obciążenia OpenStack. Zainstaluj wtyczkę load balancer (Octavia) za pomocą następującego polecenia z okna terminala na Ubuntu 22.04:
pip install python-octaviaclient
Ewentualnie, jeśli masz zainstalowany virtualenvwrapper:
mkvirtualenv python-octaviaclient
pip install python-octaviaclient
W zależności od środowiska może być konieczne użycie wariantów takich jak python3, pip3 itp.
Nr 6 Zainstalowany Terraform
Do działania wymagany jest Terraform w wersji 1.50 lub nowszej.
Pełne wprowadzenie i opis instalacji Terrafom na OpenStack znajdują się w artykule Generowanie i autoryzacja Terraform przy użyciu użytkownika Keycloak na NSIS Cloud.
Aby korzystać w tym celu z Terraform, należy uwierzytelnić się w chmurze przy użyciu poświadczeń aplikacji z nieograniczonym dostępem. Zapoznaj się z artykułem Jak wygenerować lub użyć poświadczeń aplikacji za pośrednictwem CLI na NSIS Cloud
Horizon: whitelisting dla load balancerów
Utworzymy białe listy dla load balancerów, ograniczając odpowiednie porty w ich grupach zabezpieczeń. W Horizon użyj polecenia Network –> Load Balancers, aby zobaczyć listę load balancerów:
Użyjmy load balancera o nazwie zaczynającej się od gitlab. Nie ma bezpośredniego połączenia z load balancera z grupami bezpieczeństwa, więc najpierw musimy zidentyfikować instancję, która odpowiada temu load balancerowi. Użyj poleceń Project –> Compute –> Instances i wyszukaj instancje zawierające w nazwie gitlab:
Wyedytuj grupy zabezpieczeń tych instancji - dla każdej instancji przejdź do menu Actions i wybierz Edit Security Groups.
Przefiltruj grupy zabezpieczeń według gitlab:
Użyj poleceń Project –> Network –> Security Groups, aby wyświetlić grupy zabezpieczeń mające w nazwie gitlab:
Wybierz grupę zabezpieczeń, którą chcesz edytować; alternatywnie możesz utworzyć nową grupę. W każdym przypadku należy wprowadzić następujące dane:
Direction: Ingress
Ether Type: IPv4
Protocol: TCP
Port Range: Określa zakres portów używanych przez load balancer.
Remote IP Prefix: Wprowadź adres IP lub CIDR, kóy ma być umieszczony na białej liście.
Zapisz i zastosuj zmiany.
Weryfikacja
Aby potwierdzić konfigurację:
Przejdź do sekcji Instances w aplikacji Horizon.
Wyświetl grupy zabezpieczeń zastosowane do instancji skojarzonych z load balancerami.
Upewnij się, że nowo dodana reguła jest widoczna.
CLI: whitelisting dla load balancerów
OpenStack CLI zapewnia metodę wiersza poleceń do implementacji whitelistingu adresów IP.
Upewnij się, że są spełnione warunki z Wymagań wstępnych nr 4 i 5, aby polecenie openstack było w pełni operacyjne.
Lista grup zabezpieczeń powiązanych z load balancerem:
openstack loadbalancer show <LOAD_BALANCER_NAME_OR_ID>
Zidentyfikuj pulę powiązaną z load balancerem:
openstack loadbalancer pool list
Wyświetl informacje szczegółowe o puli, aby uzyskać listę jej członków:
openstack loadbalancer pool show <POOL_NAME_OR_ID>
Zanotuj adresy IP członków puli i zidentyfikuj hostujące je instancje.
Utwórz grupę zabezpieczeń dla whitelistingu adresów IP:
openstack security group create <SECURITY_GROUP_NAME>
Dodaj reguły do grupy zabezpieczeń:
openstack security group rule create \
--ingress \
--ethertype IPv4 \
--protocol tcp \
--dst-port <PORT_RANGE> \
--remote-ip <IP_OR_CIDR> \
<SECURITY_GROUP_ID>
Zastosuj grupę zabezpieczeń do instancji hostujących członków puli:
openstack server add security group <INSTANCE_ID> <SECURITY_GROUP_NAME>
Weryfikacja
Zweryfikuj zastosowane reguły dla grupy zabezpieczeń:
openstack security group show <SECURITY_GROUP_ID>
Upewnij się, że grupa zabezpieczeń jest dołączona do odpowiednich instancji:
openstack server show <INSTANCE_ID>
Terraform: Whitelisting dla load balancerów
Terraform to narzędzie Infrastructure as Code (IaC), które może zautomatyzować proces konfigurowania whitelistingu adresów IP.
Utwórz grupę zabezpieczeń i regułę białej listy w pliku main.tf:
# main.tf
# Security Group to Whitelist IPs
resource "openstack_networking_secgroup_v2" "whitelist_secgroup" {
name = "loadbalancer_whitelist"
description = "Security group for load balancer IP whitelisting"
}
# Add Whitelist Rule for Specific IPs
resource "openstack_networking_secgroup_rule_v2" "allow_whitelist" {
direction = "ingress"
ethertype = "IPv4"
protocol = "tcp"
port_range_min = 80 # Replace with actual port range
port_range_max = 80
remote_ip_prefix = "192.168.1.0/24" # Replace with actual CIDR
security_group_id = openstack_networking_secgroup_v2.whitelist_secgroup.id
}
# Existing Instances Associated with Pool Members
resource "openstack_compute_instance_v2" "instances" {
count = 2 # Adjust to the number of pool member instances
name = "pool_member_${count.index + 1}"
flavor_id = "m1.small" # Replace with an appropriate flavor
image_id = "image-id" # Replace with a valid image ID
key_pair = "your-key-pair"
security_groups = [openstack_networking_secgroup_v2.whitelist_secgroup.name]
network {
uuid = "network-uuid" # Replace with the UUID of your network
}
}
# Associate the Load Balancer with Security Group via Instances
resource "openstack_lb_loadbalancer_v2" "loadbalancer" {
name = "my_loadbalancer"
vip_subnet_id = "subnet-id" # Replace with the subnet ID
depends_on = [openstack_compute_instance_v2.instances]
}
Zainicjuj i zastosuj konfigurację:
terraform init
terraform apply
Weryfikacja
Użyj Terraform, aby sprawdzić zastosowany stan:
terraform show
openstack server show <INSTANCE_ID>
openstack security group show <SECURITY_GROUP_ID>
Stan zabezpieczeń: przed i po whitelistingu load balancerów
Przed wdrożeniem whitelistingu adresów IP load balancer akceptuje ruch ze wszystkich źródeł. Po zakończeniu procedury:
tylko określone adresy IP mogą uzyskać dostęp do load balancera.
Nieautoryzowane próby dostępu są odrzucane.
Narzędzia weryfikacyjne
Różne narzędzia mogą zapewnić, że zabezpieczenie jest zainstalowane i działa:
- livez
Punkt końcowy monitorowania Kubernetes.
- nmap
(bezpłatny): Narzędzie do skanowania portów i weryfikacji dostępu.
- curl
(bezpłatny): Narzędzie do potwierdzanie kontroli dostępu z określonych adresów IP.
- Wireshark
(bezpłatny): Narzędzie do analizy na poziomie pakietów.
Testowanie za pomocą nmap
nmap -p <PORT> <LOAD_BALANCER_IP>
Testowanie za pomocą http i curl
curl http://<LOAD_BALANCER_IP>
Testowanie za pomocą curl i livez
Typowa odpowiedź przed zmianami byłaby następująca:
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
Typowa odpowiedź po zmianach byłaby jak poniżej:
curl -k https://<KUBE_API_IP>:6443/livez?verbose -m 5
curl: (28) Connection timed out after 5000 milliseconds
Co można zrobić dalej?
Zobacz również artykuły: