# Upgrading Wallarm Sidecar These instructions describe the steps to upgrade Wallarm Sidecar solution. ## 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/5.x/api-specification-enforcement/overview.md), as well as retrieving precise IPs for your [allowlisted, denylisted, or graylisted](https://docs.wallarm.com/5.x/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 5.3.17 -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/5.x/installation/kubernetes/sidecar-proxy/deployment.md) guide, it is most likely set to `wallarm-sidecar`. * ``: the path to the `values.yaml` file defining the Sidecar settings - you can use the one created for running the previous Sidecar version. 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 4.10.x 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/5.x/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 5.3.17 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. You can re-use the one generated during the initial deployment, no changes are required for upgrading. ### 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 5.3.17 -f ``` * ``: the name of the Helm release with the deployed Sidecar chart * ``: the namespace the Sidecar is deployed to * ``: the path to the `values.yaml` file defining the Sidecar 4.10 settings - you can use the one created for running the previous Sidecar version ### 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-5.3.17`. 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 4/4 Running 0 91m ``` 1. Send the test [Path Traversal](https://docs.wallarm.com/5.x/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.