Ana içeriğe geç

Wallarm modülleri entegre EOL NGINX Ingress controller’ı yükseltme

Bu talimatlar, dağıtılmış kullanım ömrü dolmuş (EOL) Wallarm Ingress Controller’ı (sürüm 3.6 ve altı) Wallarm node 6.x içeren yeni sürüme yükseltme adımlarını açıklar.

Wallarm nodes 3.6 and lower are not supported

You are recommended to upgrade the Wallarm nodes 3.6 and lower since these versions are not supported, they are end-of-life.

Node configuration and traffic filtration have been significantly simplified in the Wallarm node of the latest versions. Before upgrading the modules, please carefully review the list of changes and general recommendations. Please note that some settings of the latest node are incompatible with the nodes 3.6 and lower.

Yükseltilen Community Ingress NGINX Controller sürümü

Node’u 3.4 veya daha düşük bir sürümden yükseltiyorsanız, Wallarm Ingress controller’ın temel aldığı Community Ingress NGINX Controller sürümünün 0.26.2’den 1.11.8’e yükseltildiğini lütfen unutmayın.

Community Ingress NGINX Controller 1.11.8’in çalışma biçimi önemli ölçüde değiştiğinden, Wallarm Ingress controller yükseltmesi sırasında yapılandırmanın bu değişikliklere göre ayarlanması gerekir.

Bu talimatlar, muhtemelen değiştirmeniz gereken Community Ingress NGINX Controller ayarlarının bir listesini içerir. Yine de, lütfen Community Ingress NGINX Controller sürüm notlarına dayanarak yapılandırma geçişi için bireysel bir plan hazırlayın.

Gereksinimler

  • Kubernetes platform version 1.26-1.30

  • Helm package manager

  • Compatibility of your services with the Community Ingress NGINX Controller version 1.11.8

  • Access to the account with the Administrator role in Wallarm Console for the US Cloud or EU Cloud

  • Access to https://us1.api.wallarm.com for working with US Wallarm Cloud or to https://api.wallarm.com for working with EU Wallarm Cloud

  • Access to https://charts.wallarm.com to add the Wallarm Helm charts. Ensure the access is not blocked by a firewall

  • Access to the Wallarm repositories on Docker Hub https://hub.docker.com/r/wallarm. Make sure the access is not blocked by a firewall

  • Access to the IP addresses and their corresponding hostnames (if any) listed below. This is needed for downloading updates to attack detection rules and API specifications, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers

    node-data0.us1.wallarm.com - 34.96.64.17
node-data1.us1.wallarm.com - 34.110.183.149
us1.api.wallarm.com - 35.235.66.155
34.102.90.100
34.94.156.115
35.235.115.105

    node-data1.eu1.wallarm.com - 34.160.38.183
node-data0.eu1.wallarm.com - 34.144.227.90
api.wallarm.com - 34.90.110.226

Adım 1: Filtreleme node modüllerini yükselttiğinizi Wallarm teknik desteğine bildirin (yalnızca node 2.18 veya altını yükseltiyorsanız)

Node 2.18 veya altını yükseltiyorsanız, Wallarm teknik desteğine filtreleme node modüllerini 6.x’e güncellediğinizi bildirin ve Wallarm hesabınız için yeni IP listeleri mantığının etkinleştirilmesini isteyin.

Yeni IP listeleri mantığı etkinleştirildiğinde, lütfen Wallarm Console’u açın ve IP lists bölümünün mevcut olduğundan emin olun.

Adım 2: Threat Replay Testing modülünü devre dışı bırakın (yalnızca node 2.16 veya altını yükseltiyorsanız)

Wallarm node 2.16 veya altını yükseltiyorsanız, lütfen Wallarm Console → Vulnerabilities → Configure bölümünden Threat Replay Testing modülünü devre dışı bırakın.

Modülün çalışması, yükseltme süreci sırasında yanlış pozitiflere neden olabilir. Modülü devre dışı bırakmak bu riski en aza indirir.

Adım 3: API portunu güncelleyin

Starting with version 4.0, the filtering node uploads data to the Cloud using the us1.api.wallarm.com:443 (US Cloud) and api.wallarm.com:443 (EU Cloud) API endpoints instead of us1.api.wallarm.com:444 and api.wallarm.com:444.

If you upgrade the node from the version 3.x or lower and your server with the deployed node has a limited access to the external resources and the access is granted to each resource separately, then after upgrade the synchronization between the filtering node and the Cloud will stop.

To restore the synchronization, in your configuration, change port 444 to 443 for API endpoint for each resource.

Adım 4: Wallarm Helm chart deposunu güncelleyin

helm repo update wallarm

Aşağıdaki komutla tüm chart sürümlerini içeren Wallarm Helm deposunu ekleyin. Wallarm Ingress controller ile sonraki çalışmalarda lütfen Helm deposunu kullanın.

helm repo add wallarm https://charts.wallarm.com
helm repo update wallarm

Adım 5: values.yaml yapılandırmasını güncelleyin

Wallarm Ingress controller 6.x’e geçmek için values.yaml dosyasında belirtilen aşağıdaki yapılandırmayı güncelleyin:

  • Community Ingress NGINX Controller’ın standart yapılandırması

  • Wallarm modülünün yapılandırması

Community Ingress NGINX Controller’ın standart yapılandırması

  1. Community Ingress NGINX Controller sürüm notlarını 0.27.0 ve sonrası için inceleyin ve values.yaml dosyasında değiştirilecek ayarları belirleyin.

  2. Belirlenen ayarları values.yaml dosyasında güncelleyin.

Muhtemelen değiştirmeniz gereken ayarlar şunlardır:

  • İstekler Wallarm Ingress controller’a gönderilmeden önce bir yük dengeleyiciden geçiyorsa, son kullanıcı genel IP adresinin doğru raporlanması.

    controller:
  config:
-    use-forwarded-headers: "true"
+    enable-real-ip: "true"
+    forwarded-for-header: "X-Forwarded-For"

  • IngressClasses yapılandırması. Yeni Ingress controller’da kullanılan Kubernetes API sürümü yükseltildi, bu da IngressClasses’in .controller.ingressClass, .controller.ingressClassResource ve .controller.watchIngressWithoutClass parametreleri ile yapılandırılmasını gerektirir.

    controller:
+  ingressClass: waf-ingress
+  ingressClassResource:
+    name: waf-ingress
+    default: true
+  watchIngressWithoutClass: true

  • ConfigMap (.controller.config) parametre seti, örneğin: 

    controller:
config:
+  allow-backend-server-header: "false"
  enable-brotli: "true"
  gzip-level: "3"
  hide-headers: Server
  server-snippet: |
    proxy_request_buffering on;
    wallarm_enable_libdetection on;

  • "admission webhook" ile Ingress sözdizimi doğrulaması artık varsayılan olarak etkindir.

    controller:
+  admissionWebhooks:
+    enabled: true

    Ingress sözdizimi doğrulamasının devre dışı bırakılması

    Ingress sözdizimi doğrulamasını yalnızca Ingress nesnelerinin çalışmasını istikrarsızlaştırıyorsa devre dışı bırakmanız önerilir.

  • Etiket biçimi. values.yaml dosyası pod yakınlık (affinity) kuralları belirtiyorsa, bu kurallardaki etiket biçimini değiştirin, örneğin:

    controller:
  affinity:
    podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - podAffinityTerm:
        labelSelector:
            matchExpressions:
-            - key: app
+            - key: app.kubernetes.io/name
            operator: In
            values:
            - waf-ingress
-            - key: component
+            - key: app.kubernetes.io/component
            operator: In
            values:
-              - waf-ingress
+              - controller
-            - key: release
+            - key: app.kubernetes.io/instance
            operator: In
            values:
            - waf-ingress-ingress
        topologyKey: kubernetes.io/hostname
        weight: 100

Wallarm modülünün yapılandırması

values.yaml dosyasında ayarlanmış Wallarm modülü yapılandırmasını aşağıdaki gibi değiştirin:

Adım 6: overlimit_res saldırı tespiti yapılandırmasını yönergelerden kurala aktarın

Starting from the version 3.6, you can fine-tune the overlimit_res attack detection using the rule in Wallarm Console.

Earlier, the wallarm_process_time_limit and wallarm_process_time_limit_block NGINX directives have been used. The listed directives are considered to be deprecated with the new rule release and will be deleted in future releases.

If the overlimit_res attack detection settings are customized via the listed directives, it is recommended to transfer them to the rule as follows:

  1. Open Wallarm Console → Rules and proceed to the Limit request processing time rule setup.

  2. Configure the rule as done via the NGINX directives:

    • The rule condition should match the NGINX configuration block with the wallarm_process_time_limit and wallarm_process_time_limit_block directives specified.

    • The time limit for the node to process a single request (milliseconds): the value of wallarm_process_time_limit.

      Risk of running out of system memory

      The high time limit and/or continuation of request processing after the limit is exceeded can trigger memory exhaustion or out-of-time request processing.

    • The node will either block or pass the overlimit_res attack depending on the node filtration mode:

      • In the monitoring mode, the node forwards the original request to the application address. The application has the risk to be exploited by the attacks included in both processed and unprocessed request parts.
      • In the safe blocking mode, the node blocks the request if it is originated from the graylisted IP address. Otherwise, the node forwards the original request to the application address. The application has the risk to be exploited by the attacks included in both processed and unprocessed request parts.
      • In the block mode, the node blocks the request.

  3. Delete the wallarm_process_time_limit and wallarm_process_time_limit_block NGINX directives from the values.yaml configuration file.

    If the overlimit_res attack detection is fine-tuned using both the directives and the rule, the node will process requests as the rule sets.

Adım 7: Gelecek tüm K8s manifest değişikliklerini inceleyin

Ingress controller davranışının beklenmedik şekilde değişmesini önlemek için, Helm Diff Plugin kullanarak gelecek tüm K8s manifest değişikliklerini inceleyin. Bu eklenti, dağıtılmış Ingress controller sürümünün K8s manifestleri ile yenisinin manifestleri arasındaki farkı çıktılar.

Eklentiyi kurup çalıştırmak için:

  1. Eklentiyi kurun:

    helm plugin install https://github.com/databus23/helm-diff

  2. Eklentiyi çalıştırın:

    helm diff upgrade <RELEASE_NAME> -n <NAMESPACE> wallarm/wallarm-ingress --version 6.5.1 -f <PATH_TO_VALUES>
    • <RELEASE_NAME>: Ingress controller chart’ının Helm sürüm adı
    • <NAMESPACE>: Ingress controller’ın dağıtıldığı namespace
    • <PATH_TO_VALUES>: Ingress controller 6.x ayarlarını tanımlayan values.yaml dosyasının yolu

  3. Hiçbir değişikliğin çalışan servislerin stabilitesini etkilemediğinden emin olun ve stdout’tan gelen hataları dikkatlice inceleyin.

    Stdout boşsa, values.yaml dosyasının geçerli olduğundan emin olun.

Lütfen aşağıdaki yapılandırmalardaki değişikliklere dikkat edin:

  • Değiştirilemeyen (immutable) alanlar; örneğin Deployment ve/veya StatefulSet seçicileri.

  • Pod etiketleri. Değişiklikler, örneğin aşağıdaki gibi, NetworkPolicy’nin çalışmasının durmasına yol açabilir:

    apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
spec:
  egress:
  - to:
    - namespaceSelector:
        matchExpressions:
        - key: name
          operator: In
          values:
          - kube-system # ${NAMESPACE}
      podSelector:
        matchLabels: # RELEASE_NAME=waf-ingress
-         app: waf-ingress
+         app.kubernetes.io/component: "controller"
+         app.kubernetes.io/instance: "waf-ingress"
+         app.kubernetes.io/name: "waf-ingress"
-         component: waf-ingress

  • Yeni etiketlerle Prometheus yapılandırması, örneğin:

     - job_name: 'kubernetes-ingress'
   kubernetes_sd_configs:
   - role: pod
     namespaces:
       names:
         - kube-system # ${NAMESPACE}
   relabel_configs: # RELEASE_NAME=waf-ingress
     # Seçiciler
-    - source_labels: [__meta_kubernetes_pod_label_app]
+    - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name]
       action: keep
       regex: waf-ingress
-    - source_labels: [__meta_kubernetes_pod_label_release]
+    - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_instance]
       action: keep
       regex: waf-ingress
-    - source_labels: [__meta_kubernetes_pod_label_component]
+    - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_component]
       action: keep
-      regex: waf-ingress
+      regex: controller
     - source_labels: [__meta_kubernetes_pod_container_port_number]
       action: keep
       regex: "10254|18080"
       # Değiştiriciler
     - action: replace
       target_label: __metrics_path__
       regex: /metrics
     - action: labelmap
       regex: __meta_kubernetes_pod_label_(.+)
     - source_labels: [__meta_kubernetes_namespace]
       action: replace
       target_label: kubernetes_namespace
     - source_labels: [__meta_kubernetes_pod_name]
       action: replace
       target_label: kubernetes_pod_name
     - source_labels: [__meta_kubernetes_pod_name]
       regex: (.*)
       action: replace
       target_label: instance
       replacement: "$1"

  • Diğer tüm değişiklikleri analiz edin.

Adım 8: Ingress controller’ı yükseltin

Wallarm Ingress controller’ı yükseltmenin üç yolu vardır. Ortamınızda bir yük dengeleyici olup olmamasına bağlı olarak yükseltme yöntemini seçin:

  • Geçici Ingress controller dağıtımı

  • Ingress controller sürümünün olağan şekilde yeniden oluşturulması

  • Yük dengeleyiciyi etkilemeden Ingress controller sürümünün yeniden oluşturulması

Staging ortamı veya minikube kullanımı

Wallarm Ingress controller staging ortamınıza dağıtılmışsa, önce onu yükseltmeniz önerilir. Tüm servisler staging ortamında doğru şekilde çalışıyorsa, üretim ortamında yükseltme işlemine devam edebilirsiniz.

Aksi takdirde, Wallarm Ingress controller 6.x’i güncellenmiş yapılandırmayla önce minikube veya başka bir servis kullanarak dağıtmanız önerilir. Tüm servislerin beklendiği gibi çalıştığından emin olun ve ardından üretim ortamında Ingress controller’ı yükseltin.

Bu yaklaşım, üretim ortamındaki servislerin kesinti yaşamasını önlemeye yardımcı olur.

Yöntem 1: Geçici Ingress controller dağıtımı

Bu yöntemle, Ingress Controller 6.x’i ortamınıza ek bir varlık olarak dağıtabilir ve trafiği ona kademeli olarak yönlendirebilirsiniz. Bu, servislerin geçici dahi olsa kesintiye uğramasını önlemeye ve güvenli bir geçiş sağlamaya yardımcı olur.

  1. Ingress controller 6.x için values.yaml dosyasına, önceki sürümün values.yaml dosyasındaki IngressClass yapılandırmasını kopyalayın.

    Bu yapılandırmayla Ingress controller, Ingress nesnelerini tanıyacak ancak trafiğini işlemeyecektir.

  2. Ingress controller 6.x’i dağıtın:

    helm install <RELEASE_NAME> -n <NAMESPACE> wallarm/wallarm-ingress --version 6.5.1 -f <PATH_TO_VALUES>
    • <RELEASE_NAME>: Ingress controller chart’ının Helm sürüm adı
    • <NAMESPACE>: Ingress controller’ın dağıtılacağı namespace
    • <PATH_TO_VALUES>: Ingress controller 6.x ayarlarını tanımlayan values.yaml dosyasının yolu

  3. Tüm servislerin doğru şekilde çalıştığından emin olun.

  4. Yükü yeni Ingress controller’a kademeli olarak taşıyın.

Yöntem 2: Ingress controller sürümünün olağan şekilde yeniden oluşturulması

Yük dengeleyici ve Ingress controller aynı Helm chart’ında tanımlı DEĞİLSE, sadece Helm sürümünü yeniden oluşturabilirsiniz. Bu işlem birkaç dakika sürecek ve bu süre boyunca Ingress controller kullanılamayacaktır.

Helm chart bir yük dengeleyici yapılandırması da belirliyorsa

Helm chart, Ingress controller ile birlikte bir yük dengeleyici yapılandırması belirliyorsa, sürümün yeniden oluşturulması uzun bir yük dengeleyici kesintisine yol açabilir (bulut sağlayıcısına bağlıdır). Sabit bir adres atanmadıysa yükseltmeden sonra yük dengeleyici IP adresi değişebilir.

Bu yöntemi kullanıyorsanız lütfen tüm potansiyel riskleri analiz edin.

Ingress controller sürümünü yeniden oluşturmak için:

  1. Önceki sürümü silin:

    helm delete <RELEASE_NAME> -n <NAMESPACE>

    • <RELEASE_NAME>: Ingress controller chart’ının Helm sürüm adı

    • <NAMESPACE>: Ingress controller’ın dağıtıldığı namespace

    Komutu çalıştırırken lütfen --wait seçeneğini kullanmayın; bu seçenek yükseltme süresini artırabilir.

  2. Ingress controller 6.x ile yeni bir sürüm oluşturun:

    helm install <RELEASE_NAME> -n <NAMESPACE> wallarm/wallarm-ingress --version 6.5.1 -f <PATH_TO_VALUES>

    • <RELEASE_NAME>: Ingress controller chart’ının Helm sürüm adı

    • <NAMESPACE>: Ingress controller’ın dağıtılacağı namespace

    • <PATH_TO_VALUES>: Ingress controller 6.x ayarlarını tanımlayan values.yaml dosyasının yolu

  1. Yükseltme süresini azaltmak için Terraform yapılandırmasında wait = false seçenek değerini ayarlayın:

    resource "helm_release" "release" {
  ...

+ wait = false

  ...
}

  2. Önceki sürümü silin:

    terraform taint helm_release.release

  3. Ingress controller 6.x ile yeni sürümü oluşturun:

    terraform apply -target=helm_release.release

Yöntem 3: Yük dengeleyiciyi etkilemeden Ingress controller sürümünün yeniden oluşturulması

Bulut sağlayıcısı tarafından yapılandırılan bir yük dengeleyici kullanıyorsanız, yük dengeleyiciyi etkilemediği için Ingress controller’ı bu yöntemle yükseltmeniz önerilir.

Sürümün yeniden oluşturulması birkaç dakika sürecek ve bu süre boyunca Ingress controller kullanılamayacaktır.

  1. Silinecek nesneleri (yük dengeleyici hariç) alın:

    helm get manifest <RELEASE_NAME> -n <NAMESPACE> | yq -r '. | select(.spec.type != "LoadBalancer") | .kind + "/" + .metadata.name' | tr 'A-Z' 'a-z' > objects-to-remove.txt

    yq aracını kurmak için lütfen talimatları kullanın.

    Silinecek nesneler objects-to-remove.txt dosyasına yazdırılacaktır.

  2. Listelenen nesneleri silin ve sürümü yeniden oluşturun:

    cat objects-to-remove.txt | xargs kubectl delete --wait=false -n <NAMESPACE>    && \
helm upgrade <RELEASE_NAME> -n <NAMESPACE> wallarm/wallarm-ingress --version 6.5.1 -f `<PATH_TO_VALUES>`

    Servis kesintisini azaltmak için komutları ayrı ayrı çalıştırmanız ÖNERİLMEZ.

  3. Tüm nesnelerin oluşturulduğundan emin olun:

    helm get manifest <RELEASE_NAME> -n <NAMESPACE> | kubectl create -f -

    Çıktı, tüm nesnelerin zaten var olduğunu söylemelidir.

Komutlarda şu parametreler geçilir:

  • <RELEASE_NAME>: Ingress controller chart’ının Helm sürüm adı

  • <NAMESPACE>: Ingress controller’ın dağıtıldığı namespace

  • <PATH_TO_VALUES>: Ingress controller 6.x ayarlarını tanımlayan values.yaml dosyasının yolu

Adım 9: Yükseltilen Ingress controller’ı test edin

  1. Helm chart sürümünün güncellendiğini kontrol edin:

    helm ls

    Chart sürümü wallarm-ingress-6.5.1 ile uyumlu olmalıdır.

  2. Wallarm pod’unu alın:

    kubectl get pods -n <NAMESPACE> -l app.kubernetes.io/name=wallarm-ingress

    Pod durumu STATUS: Running ve READY: N/N olmalıdır:

    NAME                                                                  READY   STATUS    RESTARTS   AGE
ingress-controller-wallarm-ingress-controller-6d659bd79b-952gl        3/3     Running   0          8m7s
ingress-controller-wallarm-ingress-controller-wallarm-wstore-7ddmgbfm 3/3     Running   0          8m7s

  3. Wallarm Ingress controller adresine test Path Traversal saldırısı içeren isteği gönderin:

    curl http://<INGRESS_CONTROLLER_IP>/etc/passwd

    Filtreleme node’u block modunda çalışıyorsa, isteğe yanıtta 403 Forbidden kodu döndürülür ve saldırı Wallarm Console → Attacks bölümünde görüntülenir.

Adım 10: Ingress açıklamalarını (annotations) yayınlanan değişikliklere göre ayarlayın

Ingress controller 6.x’te yayınlanan değişikliklere göre aşağıdaki Ingress açıklamalarını ayarlayın:

  1. Sürüm 2.18 veya daha düşükten yükseltiyorsanız, IP listesi yapılandırmasını taşıyın. IP listesi çekirdek mantığı Wallarm node 3.x’te önemli ölçüde değiştiğinden, uygulanmışsa Ingress açıklamalarını değiştirerek IP listesi yapılandırmasını uygun şekilde ayarlamak gerekir.

  2. Aşağıda listelenen ayarların beklenen davranışının, off ve monitoring filtreleme modlarının değişen mantığına karşılık geldiğinden emin olun:

    Beklenen davranış filtreleme modu mantığındaki değişikliklerle uyuşmuyorsa, lütfen Ingress açıklamalarını yayınlanan değişikliklere uyacak şekilde ayarlayın.

  3. Ingress, nginx.ingress.kubernetes.io/wallarm-instance ile açıklanmışsa, bu açıklamanın adını nginx.ingress.kubernetes.io/wallarm-application olarak değiştirin.

    Yalnızca açıklama adı değişti, mantığı aynı kaldı. Eski adla açıklama yakında kullanımdan kaldırılacağından, daha önce yeniden adlandırmanız önerilir.

  4. Ingress açıklamaları ile yapılandırılmış &/usr/share/nginx/html/wallarm_blocked.html sayfası engellenen isteklere döndürülüyorsa, yapılandırmasını yayınlanan değişikliklere göre ayarlayın.

    Yeni node sürümlerinde, Wallarm engelleme sayfasının güncellenmiş bir arayüzü vardır; varsayılan olarak logo ve destek e-postası içermez.

Adım 11: Threat Replay Testing modülünü yeniden etkinleştirin (yalnızca node 2.16 veya altını yükseltiyorsanız)

Threat Replay Testing modülü kurulumu ile ilgili önerileri inceleyin ve gerekirse yeniden etkinleştirin.

Bir süre sonra, modülün çalışmasının yanlış pozitiflere yol açmadığından emin olun. Yanlış pozitifler keşfederseniz, lütfen Wallarm teknik desteği ile iletişime geçin.