ترقية نهاية عمر واجهة تحكم NGINX Ingress المتكاملة مع وحدات Wallarm¶

تصف هذه التعليمات الخطوات لترقية Wallarm Ingress Controller المنتهي العمر (الإصدار 3.6 وأدناه) إلى الإصدار الجديد مع Wallarm node 4.10.

متطلبات¶

• Kubernetes platform version 1.26-1.30

• Helm package manager

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

• 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 below for downloading updates to attack detection rules and [API specifications][api-spec-enforcement-docs], as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted][ip-lists-docs] countries, regions, or data centers

  US CloudEU Cloud

  34.96.64.17
  34.110.183.149
  35.235.66.155
  34.102.90.100
  34.94.156.115
  35.235.115.105
  

  34.160.38.183
  34.144.227.90
  34.90.110.226
  

الخطوة 1: أبلغ Wallarm technical support بالترقية¶

إذا كانت الترقية للعقدة 2.18 أو أقل، فـابلغ دعم فني Wallarm أنك تقوم بتحديث وحدات فرز العقدة إلى 4.10 واطلب تمكين منطق قوائم الأي بي الجديدة لحساب Wallarm الخاص بك.

عند تمكين منطق قوائم الأي بي الجديدة، يرجى فتح Wallarm Console والتأكد من أن القسم قوائم الأي بي متاح.

الخطوة 2: تعطيل وحدة التحقق من التهديد النشط (فقط إذا كانت الترقية للعقدة 2.16 أو أقل)¶

إذا كانت الترقية لـ Wallarm node 2.16 أو أقل، يرجى تعطيل وحدة التحقق من التهديد النشط في Wallarm Console → الثغرات الأمنية → تكوين.

يمكن أن يتسبب تشغيل الوحدة في إيجادات كاذبة أثناء عملية الترقية. يقلل تعطيل الوحدة من هذا المخاطر.

الخطوة 3: حدّث منفذ الواجهة البرمجية للتطبيق API¶

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.

الخطوة 4: حدّث مستودع Wallarm Helm¶

helm repo update wallarm

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

الخطوة 5: حدّث التكوين values.yaml¶

للانتقال إلى واجهة تحكم Wallarm Ingress 4.10، حدّث التكوين التالي المحدد في الملف values.yaml:

• التكوين القياسي لواجهة تحكم Community Ingress NGINX

• تكوين وحدة Wallarm

التكوين القياسي لواجهة تحكم Community Ingress NGINX¶

1. تحقق من ملاحظات الإصدار على واجهة تحكم Community Ingress NGINX 0.27.0 وأعلى وحدد الإعدادات التي يجب تغييرها في الملف values.yaml.

2. حدّث الإعدادات المحددة في الملف values.yaml.

هناك الإعدادات التالية التي يجب على الأرجح تغييرها:

• تقرير صحيح لعنوان الأي بي العام لمستخدم النهاية إذا تم إرسال الطلبات عبر موزع الحمل قبل إرسالها إلى واجهة تحكم Wallarm Ingress.

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

• تكوين IngressClasses. تم ترقية الإصدار من API الكوبرنتيس المستخدم في واجهة التحكم Ingress الجديدة التي تتطلب تكوين IngressClasses عبر المعلمات .controller.ingressClass, .controller.ingressClassResource و .controller.watchIngressWithoutClass.

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

• مجموعة معلمات ConfigMap (.controller.config), مثلاً:

  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;
  

• التحقق من بناء جملة Ingress عبر "admission webhook" الآن مُمكَّن بشكل افتراضي.

  controller:
  +  admissionWebhooks:
  +    enabled: true
  

  تعطيل التحقق من بناء الجملة لـ Ingress

  يُوصى بتعطيل التحقق من بناء الجملة لـ Ingress فقط إذا كان يفسد استقرار تشغيل أجسام Ingress.

• تنسيق التسمية. إذا وضع ملف values.yaml قواعد تجانس الحمولات، قم بتغيير تنسيق التسمية في هذه القواعد، مثلاً:

  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¶

قم بتغيير مجموعة تكوين وحدة Wallarm المضبوطة في ملف values.yaml كما يلي:

• إذا كانت الترقية من الإصدار 2.18 أو أقل، قم بـترحيل تكوين قائمة الأي بي. هناك المعلمات التالية المحتمل حذفها من values.yaml:

  controller:
    wallarm:
      enabled: true
      - acl:
      -  enabled: true
      resources: {}
  

  نظرًا لأن منطق الجوهر لقوائم الأي بي تغير بشكل كبير في Wallarm node 3.x، يلزم ضبط التكوين المناسب لقائمة الأي بي.

• تأكد أن السلوك المتوقع للإعدادات المدرجة أدناه يتوافق مع المنطق المتغير لوضعي الترشيح off و monitoring:

  • تعليمات wallarm_mode
  • قاعدة الترشيح العامة المكونة في Wallarm Console
  • قواعد الترشيح الهدفية نقطة النهاية المكونة في Wallarm Console

  إذا لم يتوافق السلوك المتوقع مع منطق وضع الترشيح المتغير، فالرجاء ضبط تعليمات Ingress و الإعدادات الأخرى للتغييرات المطلقة.

• التخلص من تكوين الخدمة المراقبة بشكل صريح. في إصدار واجهة تحكم Wallarm Ingress الجديدة، يتم تمكين الخدمة المراقبة بشكل افتراضي ولا تتطلب أي تكوين إضافي.

  controller:
  wallarm:
    enabled: true
    tarantool:
      resources: {}
  -  metrics:
  -    enabled: true
  -    service:
  -      annotations: {}
  

• إذا كانت الصفحة &/usr/share/nginx/html/wallarm_blocked.html المكونة عبر ConfigMap تعود إلى طلبات محظورة، اضبط تكوينها على التغييرات المطلقة.

  في إصدار العقدة الجديد، لدى الصفحة العادية للحظر بواسطة Wallarm واجهة مستخدم محدثة بدون شعار و عنوان بريد الكتروني للدعم محدد بشكل افتراضي.

• إذا كنت قد قمت بتخصيص كشف الهجوم overlimit_res من خلال توجيهات NGINX wallarm_process_time_limit وwallarm_process_time_limit_block، يرجى نقل هذه الإعدادات إلى القاعدة وحذفها من الملف values.yaml.

الخطوة 6: نقل تكوين كشف الهجوم overlimit_res من التوجيهات إلى القاعدة¶

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.

الخطوة 7: تحقق من جميع التغييرات المرتقبة لوثائق K8s¶

لتجنب تغيير سلوك واجهة تحكم Ingress بشكل غير متوقع، تحقق من جميع التغييرات المرتقبة لوثائق K8s باستخدام Helm Diff Plugin. يوفر هذا البرنامج المساعد الفرق بين وثائق K8s لإصدار واجهة تحكم Ingress المنشر والجديد.

لتثبيت وتشغيل البرنامج المساعد:

1. قم بتثبيت البرنامج المساعد:

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

2. قم بتشغيل البرنامج المساعد:

   helm diff upgrade <RELEASE_NAME> -n <NAMESPACE> wallarm/wallarm-ingress --version 4.10.4 -f <PATH_TO_VALUES>
   

   • <RELEASE_NAME>: اسم الإصدار Helm للرسم البياني لـ Ingress controller
   • <NAMESPACE>: الفضاء الاسمي الذي يتم نشر Ingress controller فيه
   • <PATH_TO_VALUES>: المسار إلى ملف values.yaml الذي يحدد إعدادات واجهة تحكم Ingress 4.10

3. تأكد أن أي تغييرات لا يمكن أن تؤثر على استقرار الخدمات الجارية ودرس الأخطاء بعناية من stdout.

   إذا كان stdout فارغًا، تأكد من أن ملف values.yaml صالح.

يرجى ملاحظة التغييرات التالية للتكوين:

• الحقل الثابت، مثل محددات التوزيع و/أو StatefulSet.

• تسميات الحمولة. التغييرات يمكن أن تؤدي إلى إنهاء عملية NetworkPolicy، على سبيل المثال:

  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
  

• تكوين Prometheus ذو التسميات الجديدة، على سبيل المثال:

   - job_name: 'kubernetes-ingress'
     kubernetes_sd_configs:
     - role: pod
       namespaces:
         names:
           - kube-system # ${NAMESPACE}
     relabel_configs: # RELEASE_NAME=waf-ingress
       # Selectors
  -    - 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"
         # Replacers
       - 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"
  

• تحليل جميع التغييرات الأخرى.

الخطوة 8: ترقية واجهة التحكم Ingress¶

هناك ثلاث طرق لترقية واجهة تحكم Wallarm Ingress. اعتمادًا على ما إذا كان هناك موزع حمل مثبت في بيئتك، قم باختيار الطريقة للترقية:

• تثبيت واجهة تحكم Ingress موقتة

• إعادة إنشاء الإصدار بشكل عادي

• إعادة إنشاء الإصدار دون التأثير على موزع الحمل

الطريقة 1: تثبيت واجهة تحكم Ingress موقتة¶

من خلال استخدام هذه الطريقة، يمكنك تثبيت واجهة تحكم Ingress 4.10 ككيان إضافي في بيئتك والتحويل إلى الحركة تدريجياً. تساعد على تجنب حتى توقف الخدمات مؤقتاً وتضمن الهجرة الآمنة.

1. قم بنسخ تكوين IngressClass من ملف values.yaml للإصدار السابق إلى ملف values.yaml لواجهة التحكم Ingress 4.10.

   مع هذا التكوين، ستتعرف واجهة التحكم Ingress على أجسام الوصول ولكن لن تقوم بمعالجة حركة مرورها.

2. قم بتثبيت واجهة تحكم Ingress 4.10:

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

   • <RELEASE_NAME>: اسم لإصدار Helm لرسم البياني لواجهة التحكم Ingress
   • <NAMESPACE>: الفضاء الاسمي حيث يتم تثبيت واجهة التحكم Ingress
   • <PATH_TO_VALUES>: المسار إلى الملف values.yaml الذي يحدد إعدادات واجهة تحكم Ingress 4.10

3. تأكد من أن جميع الخدمات تعمل بشكل صحيح.

4. قم بتحويل الحمولة إلى واجهة تحكم Ingress الجديدة تدريجيًا.

الطريقة 2: إعادة إنشاء الإصدار بشكل عادي¶

إذا كان موزع الحمل وواجهة التحكم Ingress غير موصوفة في نفس رسم الأخطية المصاحب في Helm chart، يمكنك ببساطة إعادة إنشاء الإصدار. سيستغرق الأمر عدة دقائق وواجهة التحكم Ingress ستكون غير متاحة لهذا الوقت.

لإعادة إنشاء إصدار واجهة التحكم Ingress:

الطريقة 3: إعادة إنشاء الإصدار من دون التأثير على موزع الحمل¶

عند استخدام موزع الحمل المكون من الموفر السحابي، يوصى بترقية واجهة التحكم Ingress بهذه الطريقة لأنها لا تؤثر على موزع الحمل.

سوف يستغرق إعادة إبداع الإصدار عدة دقائق وواجهة التحكم Ingress ستكون غير متاحة لهذا الوقت.

1. الحصول على الأجسام التي يجب حذفها (ما عدا موزع الحمل):

   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، يرجى استخدام التعليمات.

   سيتم إخراج الأجسام التي يجب حذفها إلى ملف objects-to-remove.txt.

2. حذف الأجسام المدرجة وإعادة إنشاء الإصدار:

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

   لتقليل وقت توقف الخدمة، فإنه لا يُوصى بتنفيذ الأوامر بشكل منفصل.

3. تأكد من أن جميع الأجسام مكونة بشكل صحيح:

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

   يجب أن يقول الناتج أن جميع الأجسام موجودة بالفعل.

هناك المعلمات التالية التي يتم تمريرها في الأوامر:

• <RELEASE_NAME>: اسم الإصدار Helm للرسم البياني لـ Ingress controller

• <NAMESPACE>: الفضاء الاسمي الذي يتم نشر Ingress controller فيه

• <PATH_TO_VALUES>: المسار إلى الملف values.yaml الذي يحدد إعدادات واجهة تحكم Ingress 4.10

الخطوة 9: اختبار واجهة التحكم Ingress المُرقاة¶

1. التحقق من أن الإصدار الخاص برسم الأخطية في Helm تم تحديثه:

   helm ls
   

   يجب أن يتوافق إصدار الرسم البياني مع wallarm-ingress-4.10.4.

2. احصل على قائمة الحمولات التي تحدد اسم واجهة التحكم Ingress في <INGRESS_CONTROLLER_NAME>:

   kubectl get pods -l release=<INGRESS_CONTROLLER_NAME>
   

   يجب أن يكون حالة كل حمولة الحالة: التشغيل أو جاهز: N/N. على سبيل المثال:

   NAME                                                              READY     STATUS    RESTARTS   AGE
   ingress-controller-nginx-ingress-controller-675c68d46d-cfck8      3/3       Running   0          5m
   ingress-controller-nginx-ingress-controller-wallarm-tarantljj8g   4/4       Running   0          5m
   

3. أرسل الطلب مع الاختبار Path Traversal الهجوم إلى عنوان واجهة التحكم Ingress:

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

   إذا كانت العقدة تعمل في وضع block، سيرد الرمز 403 Forbidden كرد على الطلب وسيتم عرض الهجوم في Wallarm Console → الهجمات.

الخطوة 10: ضبط التعليمات البرمجية لـ Ingress حسب التغييرات المطلقة¶

قم بضبط التعليمات البرمجية التالية لـ Ingress وفقًا للتغييرات المطلقة في واجهة التحكم Ingress 4.10:

1. إذا كانت الترقية من الإصدار 2.18 أو أقل، قم بـترحيل تكوين قائمة الأي بي. نظرًا لأن منطق الجوهر لقوائم الأي بي تغير بشكل كافٍ في Wallarm node 3.x، يجب ضبط التكوين الموائم لقائمة الأي بي من خلال تغيير التعليمات البرمجية لـ Ingress (إذا تم تطبيقه).

2. تأكد أن السلوك المتوقع للإعدادات المدرجة أدناه يتوافق مع المنطق المتغير لوضعي الترشيح off و monitoring:

   • تعليمات wallarm_mode
   • قاعدة الترشيح العامة المكونة في Wallarm Console
   • قواعد الترشيح الهدفية نقطة النهاية المكونة في Wallarm Console

   إذا لم يتوافق السلوك المتوقع مع منطق وضع الترشيح المتغير، فالرجاء ضبط تعليمات Ingress للتغييرات المطلقة.

3. إذا كان الإصدار مشفر بـ nginx.ingress.kubernetes.io/wallarm-instance، قم بتغيير هذا التعليم مع البرمجة إلى nginx.ingress.kubernetes.io/wallarm-application.

   فقط اسم التعليمات تغير، بينما بقي منطقها كما هو. سيتم إهمال التعليمات بالاسم السابق قريبًا لذا يُوصى بتغيير اسمها قبل ذلك.

4. إذا كانت الصفحة &/usr/share/nginx/html/wallarm_blocked.html المكونة عبر تعليمات Ingress تمرة إلى طلبات محظورة، اضبط تكوينها على التغييرات المطلقة.

   في إصدار تحديث العقدة، لدى الصفحة المعاد حظرها من Wallarm واجهة مستخدم محدثة من دون شعار وعنوان البريد الإلكتروني المدعوم مخصص بشكل افتراضي.

الخطوة 11: إعادة تمكين وحدة التحقق من التهديد النشط (فقط إذا كانت الترقية للعقدة 2.16 أو أقل)¶

تعلم التوصيات على إعداد وحدة التحقق من التهديد النشط وقم بإعادة تمكينها إذا كان مطلوبًا.

بعد فترة، تأكد من أن تشغيل الوحدة لا يسبب إيجادات كاذبة. إذا تم اكتشاف الإيجادات الكاذبة، يرجى الاتصال بـ دعم فني Wallarm.

هل كانت هذه الصفحة مفيدة؟

كيف يمكننا تحسين هذه المقالة؟ (خياري)

المعلومات غير واضحة أو محيرة

معلومات غير كافية

معلومات قديمة أو غير صحيحة

0/240

يرسل