Skip to content

Upgrading NGINX Ingress controller with integrated Wallarm API Security modules

These instructions describe the steps to update deployed Wallarm Ingress Controller to the new version with Wallarm node 3.4.

Breaking changes and recommendations for different node type upgrade

  • If upgrading Wallarm node 2.18 or lower, please note that version 3.x contains breaking changes. Before upgrading the modules of 2.18 and lower up to 3.4, please carefully review the list of Wallarm node changes and consider a possible configuration change.
  • We recommend to upgrade both the regular (client) and partner nodes of version 3.2 or lower up to version 3.4. It allows to stay up to date with Wallarm releases and prevent installed module deprecation.

Step 1: Inform Wallarm technical support that you are updating filtering node modules

If updating Wallarm node 2.18 or lower, inform Wallarm technical support that you are updating filtering node modules up to 3.4 and ask to enable new IP lists logic for your Wallarm account.

When new IP lists logic is enabled, please open the Wallarm Console and ensure that the section IP lists is available.

Step 2: Clone new Helm chart version from the Wallarm repository

git clone https://github.com/wallarm/ingress-chart --branch 3.4.0  --single-branch

Step 3: Upgrade the previous Helm chart

helm upgrade <INGRESS_CONTROLLER_NAME> ingress-chart/wallarm-ingress -n <KUBERNETES_NAMESPACE>
  • <INGRESS_CONTROLLER_NAME> is the name of the deployed Wallarm Ingress controller

  • <KUBERNETES_NAMESPACE> is the namespace of deployed Ingress and Ingress controller

Parameters specified with the option --set during the Ingress controller deployment will not be changed.

To add or update the parameters of the upgraded Helm chart, use one more command helm upgrade with the options --set and --reuse-values. To delete parameters, edit Wallarm ConfigMap.

Step 4: Adjust the Ingress and Helm chart configuration to changes released in version 3.x

If you have upgraded the Helm chart of version 3.0 or lower, adjust the following configurations to changes released in version 3.x:

  1. If you have upgraded the Helm chart of version 2.18 or lower, IP address lists. If you have configured IP whitelists and blacklists in version 2.18 or lower, adjust the list settings using the instructions.

    Since IP list core logic has been significantly changed in Wallarm node 3.x, it is required to adjust IP list configuration appropriately by changing Wallarm ConfigMap parameters and Ingress annotations.

  2. Ensure that the expected behavior of settings listed below corresponds to the changed logic of the off and monitoring filtration modes:

    If the expected behavior does not correspond to the changed filtration mode logic, please adjust the Ingress annotations and other settings to released changes.

Step 5: Move custom configuration specified in the values.yaml file to the --set option of helm upgrade

If some Ingress controller parameters have been configured via values.yaml cloned from the Wallarm Helm Chart repository, please copy and pass them to a new chart by using the option --set of the command helm upgrade --reuse-values.

For example, if the parameter wallarm_block_page_add_dynamic_path has been set via the file values.yaml, you can move this parameter to the new version of the Helm chart by using the following command:

helm upgrade --reuse-values --set controller.config.http-snippet='wallarm_block_page_add_dynamic_path /usr/custom-block-pages/block_page_firefox.html /usr/share/nginx/html/wallarm_blocked.html; map $http_user_agent $block_page { "~Firefox" &/usr/custom-block-pages/block_page_firefox.html; "~Chrome" &/usr/custom-block-pages/block_page_chrome.html; default &/usr/share/nginx/html/wallarm_blocked.html;}' <INGRESS_CONTROLLER_NAME> ingress-chart/wallarm-ingress -n <KUBERNETES_NAMESPACE>

The option --reuse-values allows keeping intact already configured Helm chart parameters that not passed in the --set option. The option --set specifies the Helm chart parameters to be changed or added.

Step 6: Test the upgraded Ingress controller

  1. Check that the version of the Helm chart was updated:

    helm ls
    

    The chart version should correspond to wallarm-ingress-3.4.0.

  2. Get the list of pods specifying the name of the Wallarm Ingress controller in <INGRESS_CONTROLLER_NAME>:

    kubectl get pods -l release=<INGRESS_CONTROLLER_NAME>
    

    Each pod status should be STATUS: Running or READY: N/N. For example:

    NAME                                                              READY     STATUS    RESTARTS   AGE
    ingress-controller-nginx-ingress-controller-675c68d46d-cfck8      3/3       Running   0          5m
    ingress-controller-nginx-ingress-controller-wallarm-tarantljj8g   8/8       Running   0          5m
    ingress-controller-nginx-ingress-default-backend-584ffc6c7xj5xx   1/1       Running   0          5m
    
  3. Send the request with test SQLI and XSS attacks to the Wallarm Ingress controller address:

    curl http://<INGRESS_CONTROLLER_IP>/?id='or+1=1--a-<script>prompt(1)</script>'
    

    If the filtering node is working in the block mode, the code 403 Forbidden will be returned in the response to the request and attacks will be displayed in the Wallarm Console → Nodes.