# Upgrading Wallarm Sidecar These instructions describe the steps to upgrade Wallarm Sidecar solution up to the latest 6.x version. ## Requirements * Kubernetes platform version 1.19-1.29 * [Helm v3](https://helm.sh/) package manager * An application deployed as a Pod in a Kubernetes cluster * Access to the Wallarm API host for your Cloud: `https://us1.api.wallarm.com`, `https://api.wallarm.com`, or `https://me1.api.wallarm.com` * Access to `https://charts.wallarm.com` to add the Wallarm Helm charts * Access to the Wallarm repositories on Docker Hub `https://hub.docker.com/r/wallarm` * 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](https://docs.wallarm.com/api-specification-enforcement/overview.md), as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted](https://docs.wallarm.com/user-guides/ip-lists/overview.md) countries, regions, or data centers **US Cloud:** ``` 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 ``` **EU Cloud:** ``` 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 ``` **ME Cloud:** ``` node-data0.me1.wallarm.com - 34.166.82.208 node-data1.me1.wallarm.com - 34.166.82.208 me1.api.wallarm.com - 34.166.82.208 ``` * Access to the account with the **Administrator** role in Wallarm Console for the [US Cloud](https://us1.my.wallarm.com/) or the [EU Cloud](https://my.wallarm.com/), or [ME Cloud](https://me1.my.wallarm.com/) ## Step 1: Update the Wallarm Helm chart repository ```bash helm repo update wallarm ``` ## Step 2: Check out all coming K8s manifest changes To avoid unexpectedly changed Sidecar behavior, check out all coming K8s manifest changes using [Helm Diff Plugin](https://github.com/databus23/helm-diff). This plugin outputs the difference between the K8s manifests of the deployed Sidecar version and of the new one. To install and run the plugin: 1. Install the plugin: ```bash helm plugin install https://github.com/databus23/helm-diff ``` 2. Run the plugin: ```bash helm diff upgrade -n wallarm-sidecar wallarm/wallarm-sidecar --version 6.12.1 -f ``` * `` is the name of the Wallarm Sidecar Helm release. * `wallarm-sidecar` is the namespace where the Wallarm Sidecar solution has been deployed. According to our [deployment](https://docs.wallarm.com/installation/kubernetes/sidecar-proxy/deployment.md) guide, it is most likely set to `wallarm-sidecar`. * `` is the path to the `values.yaml` file with Sidecar Helm chart 6.x settings. You can reuse the previous version's file, updating it [for the Tarantool-to-wstore transition](https://docs.wallarm.com/updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics): Helm values renamed: `postanalytics.tarantool` → `postanalytics.wstore`. Apply this change in `values.yaml` if postanalytics memory is explicitly [allocated](https://docs.wallarm.com/installation/kubernetes/sidecar-proxy/scaling.md). 3. Make sure that no changes can affect the stability of the running services and carefully examine the errors from stdout. If stdout is empty, make sure that the `values.yaml` file is valid. ## Upgrading from version 4.10.6 or lower The release 4.10.7 introduced breaking changes, requiring a reinstallation of the solution. The default method for generating the admission webhook certificate has been replaced with the [`certgen`](https://github.com/kubernetes/ingress-nginx/tree/main/images/kube-webhook-certgen) process. During the upgrade, certificates will be automatically generated using the new `certgen` process. Additionally, this release allows you to use [`cert-manager` for admission webhook certificate provisioning or specify certificates manually](https://docs.wallarm.com/installation/kubernetes/sidecar-proxy/customization.md#certificates-for-the-admission-webhook). ### Step 3: Uninstall the previous version of the solution ``` helm uninstall -n wallarm-sidecar ``` ### Step 4: Remove previous certificate artifacts ``` kubectl delete MutatingWebhookConfiguration -wallarm-sidecar kubectl delete secret -wallarm-sidecar-admission-tls -n wallarm-sidecar ``` ### Step 5: Deploy the new solution version ``` bash helm install --version 6.12.1 wallarm/wallarm-sidecar --wait -n wallarm-sidecar -f ``` * `` is the name for the Helm release. It is recommended to re-use the same name you used for the initial deployment of the solution. * `wallarm-sidecar` is the namespace to deploy the Helm release. It is recommended to re-use the same namespace you used for the initial deployment of the solution. * `` is the path to the `values.yaml` file with Sidecar Helm chart 6.x settings. You can reuse the previous version's file, updating it [for the Tarantool-to-wstore transition](https://docs.wallarm.com/updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics): Helm values renamed: `postanalytics.tarantool` → `postanalytics.wstore`. Apply this change in `values.yaml` if postanalytics memory is explicitly [allocated](https://docs.wallarm.com/installation/kubernetes/sidecar-proxy/scaling.md). ### Step 6: Restart deployments with attached Sidecar Proxy To upgrade the proxy containers already injected into application pods, restart the corresponding deployments: ``` kubectl rollout restart deployment -n ``` * `` is the name of the application deployment * `` is the namespace the deployment resides in ## Upgrading from version 4.10.7 or above ### Step 3: Upgrade the Sidecar solution Upgrade the deployed components of the Sidecar solution: ``` bash helm upgrade -n wallarm/wallarm-sidecar --version 6.12.1 -f ``` * ``: the name of the Helm release with the deployed Sidecar chart * ``: the namespace the Sidecar is deployed to * `` is the path to the `values.yaml` file with Sidecar Helm chart 6.x settings. You can reuse the previous version's file, updating it [for the Tarantool-to-wstore transition](https://docs.wallarm.com/updating-migrating/what-is-new.md#replacing-tarantool-with-wstore-for-postanalytics): Helm values renamed: `postanalytics.tarantool` → `postanalytics.wstore`. Apply this change in `values.yaml` if postanalytics memory is explicitly [allocated](https://docs.wallarm.com/installation/kubernetes/sidecar-proxy/scaling.md). ### Step 4: Restart deployments with attached Sidecar Proxy To upgrade the proxy containers already injected into application pods, restart the corresponding deployments: ``` kubectl rollout restart deployment -n ``` * `` is the name of the application deployment * `` is the namespace the deployment resides in ## Test the upgraded Sidecar solution 1. Make sure the version of the Helm chart was upgraded: ```bash helm list -n wallarm-sidecar ``` Where `wallarm-sidecar` is the namespace the Sidecar is deployed to. You can change this value if the namespace is different. The chart version should correspond to `wallarm-sidecar-6.12.1`. 1. Get the Wallarm control plane details to check it has been successfully started: ```bash kubectl get pods -n wallarm-sidecar -l app.kubernetes.io/name=wallarm-sidecar ``` Each pod should display the following: **READY: N/N** and **STATUS: Running**, e.g.: ``` NAME READY STATUS RESTARTS AGE wallarm-sidecar-controller-54cf88b989-gp2vg 1/1 Running 0 91m wallarm-sidecar-postanalytics-86d9d4b6cd-hpd5k 3/3 Running 0 91m ``` 1. Send the test [Path Traversal](https://docs.wallarm.com/attacks-vulns-list.md#path-traversal) attack to the application cluster address: ```bash curl http:///etc/passwd ``` The requested application Pod should have the `wallarm-sidecar: enabled` label. Check that the solution of the newer version processes the malicious request as it did in the previous version.