• »
  • KUBERNETES »
  • Konfiguracja białej listy IP dla OpenStack Load Balancer przy użyciu Terraform na NSIS

Konfiguracja białej listy IP dla OpenStack Load Balancer przy użyciu Terraform na NSIS

W tym przewodniku wyjaśniono, jak skonfigurować białą listę adresów IP (allowed_cidrs) na istniejącym Load Balancerze OpenStack przy użyciu Terraform. Konfiguracja ograniczy dostęp do klastra za pośrednictwem load balancera.

Co będziemy omawiać

  • Uzyskaj niezbędne dane load balancera i klastra z aplikacji Wymagania wstępne

  • Tworzenie konfiguracji Terraform

  • Importowanie istniejącego odbiornika Load Balancer

  • Uruchom terraformowanie

  • Przetestuj i sprawdź, czy ochrona load balancera za pomocą białej listy działa.

Wymagania wstępne

Nr 1 Konto

Potrzebne jest konto hostingowe NSIS z dostępem do interfejsu Horizon: https://horizon.cloudferro.com.

Nr 2 Podstawowe parametry już zdefiniowane dla białej listy

Zobacz artykuł Konfigurowanie białej listy IP dla OpenStack Load Balancer przy użyciu Horizon i CLI w NSIS dla definicji podstawowych pojęć i parametrów.

Nr 3 Zainstalowany Terraform

Do działania wymagana jest wersja 1.50 lub nowsza.

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.

Nr 4 Poświadczenia aplikacji bez ograniczeń

Musisz mieć poświadczenia aplikacji OpenStack z nieograniczonym polem wyboru. Sprawdź artykuł Jak wygenerować lub użyć poświadczeń aplikacji za pośrednictwem CLI na NSIS Cloud

Pierwsza część tego artykułu opisuje, jak zainstalować klienta OpenStack i podłączyć go do chmury. Dzięki temu najszybszym sposobem na utworzenie nieograniczonego poświadczenia aplikacji jest zastosowanie polecenia w następujący sposób:

openstack application credential create cred_unrestricted --unrestricted

Spowoduje to utworzenie nieograniczonego poświadczenia o nazwie cred_unrestricted.

Można również użyć poleceń Horizon Identity –> Application Credentials –> Create Application Credential i zaznaczyć odpowiednie pole:

../_images/whitelisting-loadbalancer-1.png

Zaloguj się na swoje konto przy użyciu tych nieograniczonych danych uwierzytelniających.

Przygotowanie środowiska

Zapoznaj się z artykułem w Warunku wstępnym nr 2, z którego wyprowadzimy wszystkie parametry wejściowe, używając poleceń Horizon i CLI.

Uwierzytelnij się również za pomocą danych uwierzytelniających aplikacji, które otrzymałeś w punkcie 4.

Konfiguracja Terraform dla białej listy

Zamiast wykonywać procedurę whitelisting ręcznie, możemy użyć Terraform i zapisać procedurę w zdalnym repozytorium.

Utwórz plik openstack_auth.sh

export OS_AUTH_URL="https://your-openstack-url:5000/v3"
export OS_PROJECT_NAME="your-project"
export OS_USERNAME="your-username"
export OS_PASSWORD="your-password"
export OS_REGION_NAME="your-region"

Utwórz nowy katalog dla konfiguracji Terraform i utwórz następujące pliki:

Informacja

Ten przykład został stworzony dla zupełnie nowego klastra Magnum. Może być konieczne dostosowanie go do własnych potrzeb.

Utwórz plik Terraform:

main.tf

terraform {
  required_providers {
    openstack = {
      source  = "terraform-provider-openstack/openstack"
      version = "1.47.0"
    }
  }
}

provider "openstack" {
  use_octavia = true  # Required for Load Balancer v2 API
}

variables.tf

variable "ID_OF_LOADBALANCER" {
  type        = string
  description = "ID of the existing OpenStack Load Balancer"
}

variable "allowed_cidrs" {
  type        = list(string)
  description = "List of IP ranges in CIDR format to whitelist"
}

terraform.tfvars

ID_OF_LOADBALANCER = "your-lb-id"
allowed_cidrs      = [
  "10.0.0.1/32",    # Single IP address
  "192.168.1.0/24", # IP range
  "172.16.0.0/16"   # Larger subnet
]

lb.tf

resource "openstack_lb_listener_v2" "k8s_api_listener" {
    loadbalancer_id = var.ID_OF_LOADBALANCER
    allowed_cidrs   = var.allowed_cidrs
    protocol_port   = "6443"
    protocol        = "TCP"
}

Importowanie istniejącego odbiornika Load Balancer

Od wersji Terraform 1.5 można importować zasoby w sposób deklaratywny.

import.tf

import {
  to = openstack_lb_listener_v2.k8s_api_listener
  id = "your-listener-id"
}

Można też zrobić to w sposób imperatywny:

terraform import openstack_lb_listener_v2.k8s_api_listener "<your-listener-id>"

Uruchom Terraform

Terraform Execute

terraform init
terraform plan -out=generated_listener.tf
terraform apply generated_listener.tf

Przykładowe dane wyjściowe:.

wyjścieteraform

Terraform apply generated_listener.tf
openstack_lb_listener_v2.k8s_api_listener: Preparing import... [id=bbf39f1c-6936-4344-9957-7517d4a979b6]
openstack_lb_listener_v2.k8s_api_listener: Refreshing state... [id=bbf39f1c-6936-4344-9957-7517d4a979b6]

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # openstack_lb_listener_v2.k8s_api_listener will be updated in-place
  # (imported from "bbf39f1c-6936-4344-9957-7517d4a979b6")
  ~ resource "openstack_lb_listener_v2" "k8s_api_listener" {
        admin_state_up            = true
      ~ allowed_cidrs             = [
          + "10.0.0.1/32",
        ]
        connection_limit          = -1
        default_pool_id           = "5991eacc-5869-4205-a646-d27646ccb216"
        default_tls_container_ref = null
        description               = null
        id                        = "bbf39f1c-6936-4344-9957-7517d4a979b6"
        insert_headers            = {}
        loadbalancer_id           = "2d6b335f-fb05-4496-8593-887f7e2c49cf"
        name                      = "lb-testing-ih347dstxyl2-api_lb_fixed-w2im3obvdv2p-listener-t36tocd4onxk"
        protocol                  = "TCP"
        protocol_port             = 6443
        region                    = "<concealed by 1Password>"
        sni_container_refs        = []
        tenant_id                 = "<concealed by 1Password>"
        timeout_client_data       = 50000
        timeout_member_connect    = 5000
        timeout_member_data       = 50000
        timeout_tcp_inspect       = 0

      - timeouts {}
    }

Plan: 1 to import, 0 to add, 1 to change, 0 to destroy.

Testy

Domyślnie Magnum LB nie ma żadnych ograniczeń dostępu.

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

Po:.

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 Wdrażanie białej listy adresów IP dla Load Balancerów z grupami zabezpieczeń w NSIS