Deploying Wallarm Sidecar¶
To secure an application deployed as a Pod in a Kubernetes cluster, you can run the NGINX-based Wallarm node in front of the application as a sidecar controller. Wallarm sidecar controller will filter incoming traffic to the application Pod by allowing only legitimate requests and mitigating malicious ones.
The key features of the Wallarm Sidecar solution:
Simplifies protection of discrete microservices and their replicas and shards by providing the deployment format that is similar to applications
Fully compatible with any Ingress controller
Works stable under high loads that is usually common for the service mesh approach
Requires minimum service configuration to secure your apps; just add some annotations and labels for the application pod to protect it
Supports two modes of the Wallarm container deployment: for medium loads with the Wallarm services running in one container and for high loads with the Wallarm services split into several containers
Provides a dedicated entity for the postanalytics module that is the local data analytics backend for the Wallarm sidecar solution consuming most of the memory
If you are using the earlier Wallarm Sidecar solution
If you are using the previous version of the Wallarm Sidecar solution, we recommend you migrate to the new one. With this release, we updated our Sidecar solution to leverage new Kubernetes capabilities and a wealth of customer feedback. The new solution does not require significant Kubernetes manifest changes, to protect an application, just deploy the chart and add labels and annotations to the pod.
For assistance in migrating to the Wallarm Sidecar solution v2.0, please contact Wallarm technical support.
Among all supported Wallarm deployment options, this solution is the recommended one for the following use cases:
You are looking for the security solution to be deployed to the infrastructure with the existing Ingress controller (e.g. AWS ALB Ingress Controller) preventing you from deployment of either Wallarm NGINX-based or Wallarm Kong-based Ingress controller
Zero-trust environment that requires each microservice (including internal APIs) to be protected by the security solution
Traffic flow with Wallarm Sidecar:
The Wallarm Sidecar solution is arranged by the following Deployment objects:
Sidecar controller (
wallarm-sidecar-controller) is the mutating admission webhook that injects Wallarm sidecar resources into the Pod configuring it based on the Helm chart values and pod annotations and connecting the node components to the Wallarm Cloud.
Once a new pod with the
wallarm-sidecar: enabledlabel in Kubernetes starts, the controller automatically injects the additional container filtering incoming traffic into the pod.
Postanalytics module (
wallarm-sidecar-postanalytics) is the local data analytics backend for the Wallarm sidecar solution. The module uses the in-memory storage Tarantool and the set of some helper containers (like the collectd, attack export services).
The Wallarm Sidecar has 2 standard stages in its lifecycle:
At the initial stage, the controller injects Wallarm sidecar resources into the Pod configuring it based on the Helm chart values and pod annotations and connecting the node components to the Wallarm Cloud.
At the runtime stage, the solution analyzes and proxies/forwards requests involving the postanalytics module.
Kubernetes platform version 1.19-1.25
Helm v3 package manager
An application deployed as a Pod in a Kubernetes cluster
https://us1.api.wallarm.comfor working with US Wallarm Cloud or to
https://api.wallarm.comfor working with EU Wallarm Cloud
https://charts.wallarm.comto add the Wallarm Helm charts
Access to the Wallarm repositories on Docker Hub
Access to the IP addresses of Google Cloud Storage listed within the link. When you allowlist, denylist, or graylist entire countries, regions, or data centers instead of individual IP addresses, the Wallarm node retrieves precise IP addresses related to the entries in the IP lists from the aggregated database hosted on Google Storage
To deploy the Wallarm Sidecar solution:
Generate a filtering node token.
Deploy the Wallarm Helm chart.
Attach the Wallarm Sidecar to the application Pod.
Test the Wallarm Sidecar operation.
Step 1: Generate a filtering node token¶
Generate a filtering node token of the appropriate type to connect the sidecar pods to the Wallarm Cloud:
Step 2: Deploy the Wallarm Helm chart¶
Add the Wallarm chart repository:
values.yamlfile with the Wallarm Sidecar configuration. Example of the file with the minimum configuration is below.
When using an API token, specify a node group name in the
nodeGroupparameter. Your nodes created for the sidecar pods will be assigned to this group, shown in the Wallarm Console's Nodes section. The default group name is
defaultSidecarGroup. If required, you can later set filtering node group names individually for the pods of the applications they protect, using the
<NODE_TOKEN>is the token of the Wallarm node to be run in Kubernetes.
Using one token for several installations
You can use one token in several installations regardless of the selected platform. It allows logical grouping of node instances in the Wallarm Console UI. Example: you deploy several Wallarm nodes to a development environment, each node is on its own machine owned by a certain developer.
Deploy the Wallarm Helm chart:
<RELEASE_NAME>is the name for the Helm release of the Wallarm Sidecar chart
wallarm-sidecaris the new namespace to deploy the Helm release with the Wallarm Sidecar chart, it is recommended to deploy it to a separate namespace
<PATH_TO_VALUES>is the path to the
Step 3: Attach the Wallarm Sidecar to the application Pod¶
For Wallarm to filter application traffic, add the
wallarm-sidecar: enabled label to the corresponding application Pod:
wallarm-sidecarapplication Pod label is either set to
disabledor not explicitly specified, the Wallarm Sidecar container is not injected into a pod and therefore Wallarm does not filter traffic.
wallarm-sidecarapplication Pod label is set to
enabled, the Wallarm Sidecar container is injected into a pod and therefore Wallarm filters incoming traffic.
Step 4: Test the Wallarm Sidecar operation¶
To test that the Wallarm Sidecar operates correctly:
Get the Wallarm control plane details to check it has been successfully started:
Each pod should display the following: READY: N/N and STATUS: Running, e.g.:
Get the application pod details to check the Wallarm sidecar container has been successfully injected:
The output should display READY: 2/2 pointing to successful sidecar container injection and STATUS: Running pointing to successful connection to the Wallarm Cloud:
Send the test Path Traversal attack to the application cluster address Wallarm is enabled to filter traffic:
Since the Wallarm proxy operates in the monitoring filtration mode by default, the Wallarm node will not block the attack but will register it.
To check that the attack has been registered, proceed to Wallarm Console → Attacks:
Wallarm pods have been injected based on the default
values.yaml and the custom configuration you specified on the 2nd deployment step.
You can customize the Wallarm proxy behavior even more on both the global and per-pod levels and get the most out of the Wallarm solution for your company.
Just proceed to the Wallarm proxy solution customization guide.
- Credential stuffing detection is currently unsupported, as the Helm chart has not been updated to the 4.10 release yet