Wdrażanie białej listy adresów IP dla Load Balancerów z grupami zabezpieczeń w NSIS
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ę białej listy IP.
Co będziemy omawiać
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
Potrzebne jest konto hostingowe NSIS z dostępem do interfejsu Horizon: https://horizon.cloudferro.com.
Nr 2 Lista adresów IP/zakresów do umieszczenia na białej liście
Jest to lista adresów IP, które mają być nasłuchiwane przez load balancer.
Nr 3 Prekonfigurowany load balancer
W OpenStack za każdym razem, gdy tworzony jest klaster Kubernetes, automatycznie tworzone są odpowiednie load balancery.
Zobacz artykuł Jak utworzyć klaster Kubernetes przy użyciu NSIS OpenStack Magnum.
Nr 4 Komenda OpenStack działa
Jest to niezbędne dla procedur CLI.
Sprowadza się to do pozyskania odpowiedniego pliku RC z Horizon. Zobacz 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 Python Octavia Client (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
Lub, 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 potrzebna będzie platforma Terraform w wersji 1.50 lub nowszej.
Pełne wprowadzenie i instalacja Terrafom na OpenStack znajduje się w artykule Generowanie i autoryzacja Terraform przy użyciu użytkownika Keycloak na NSIS Cloud.
Aby korzystać z Terraform w tym charakterze, należy uwierzytelnić się w chmurze przy użyciu poświadczeń aplikacji z nieograniczonym dostępem. Sprawdź artykuł Jak wygenerować lub użyć poświadczeń aplikacji za pośrednictwem CLI na NSIS Cloud
Horizon: Load Balancery na białej liście
Umieścimy load balancery na białej liście, 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 do grup 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 gitlab w nazwie:
Edytuj grupy zabezpieczeń tych instancji - dla każdej instancji przejdź do menu Akcje i wybierz Edytuj grupy zabezpieczeń.
Filtruj według gitlab:
Użyj poleceń Project –> Network –> Security Groups, aby wyświetlić grupy zabezpieczeń z gitlab w nazwie:
Wybierz tę, którą chcesz edytować; alternatywnie możesz utworzyć nową grupę zabezpieczeń. W każdym razie należy wprowadzić następujące dane:
Kierunek: Wejście
Typ Ether: IPv4
Protokół: TCP
Zakres portów: Określa zakres portów używanych przez load balancer.
Prefiks zdalnego IP: Wprowadź adres IP lub CIDR do umieszczenia na białej liście.
Zapisz i zastosuj zmiany.
Weryfikacja
Aby potwierdzić konfigurację:
Przejdź do sekcji Instancje w aplikacji Horizon.
Wyświetl grupy zabezpieczeń zastosowane do wystąpień skojarzonych z load balancerami.
Upewnij się, że nowo dodana reguła jest widoczna.
CLI: Load Balancery na białej liście
OpenStack CLI zapewnia metodę wiersza poleceń do implementacji białej listy IP.
Upewnij się, że spełniłeś wymagania wstępne 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
Pokaż szczegóły puli, aby wyświetlić 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 białej listy adresów IP:
openstack security group create <SECURITY_GROUP_NAME>
Dodawanie reguł 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 wystąpień hostujących członków puli:
openstack server add security group <INSTANCE_ID> <SECURITY_GROUP_NAME>
Weryfikacja
Zweryfikuj zastosowane reguły 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: Biała lista Load Balancerów
Terraform to narzędzie Infrastructure as Code (IaC), które może zautomatyzować proces konfigurowania białej listy 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 bezpieczeństwa: Przed i po umieszczeniu balancerów na białej liście
Przed wdrożeniem białej listy 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 weryfikacji
Różne narzędzia mogą zapewnić, że ochrona jest zainstalowana i aktywna:
- livez
Punkt końcowy monitorowania Kubernetes.
- nmap
(bezpłatny): Do skanowania portów i weryfikacji dostępu.
- zwijać się
(bezpłatny): Potwierdzenie kontroli dostępu z określonych adresów IP.
- Wireshark
(bezpłatny): Do analizy na poziomie pakietów.
Testowanie za pomocą nmap
nmap -p <PORT> <LOAD_BALANCER_IP>
Testowanie za pomocą http i zwijać się
curl http://<LOAD_BALANCER_IP>
Testowanie za pomocą zwijać się i livez
Byłaby to typowa reakcja przed zmianami:
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
I byłaby to typowa reakcja po zmianach:
curl -k https://<KUBE_API_IP>:6443/livez?verbose -m 5
curl: (28) Connection timed out after 5000 milliseconds
Co robić dalej
Porównaj z artykułami: