Kubernetes deployment based on Helm charts¶
These instructions provide you with the steps to deploy Wallarm as the K8s sidecar container in the Helm chart-based K8s environment.
Prerequisites¶
-
Local or cloud (EKS, GKE, AKE, etc) cluster running any version of Kubernetes
-
Application packaged as a Helm chart
-
Pod exposed to the public Internet or other potential sources of malicious web and API attacks
-
Kubernetes Ingress controller or external load balancer (like AWS ELB or ALB) to add the HTTP request header
X-Forwarded-For
, which contains the real public IP address of the connecting client -
Username and password of the user with the Deploy role added to your company's Wallarm account. To add a new user, please follow these instructions
Installation¶
-
Create Wallarm ConfigMap.
-
Update the definition of the
Deployment
object in Kubernetes. -
Update the definition of the
Service
object in Kubernetes. -
Update the Helm chart configuration file.
-
Test the Wallarm sidecar container.
If you deploy several Wallarm nodes
All Wallarm nodes deployed to your environment must be of the same versions. The postanalytics modules installed on separated servers must be of the same versions too.
Before installation of the additional node, please ensure its version matches the version of already deployed modules. If the deployed module version is deprecated or will be deprecated soon (4.0
or lower), upgrade all modules to the latest version.
The version of deployed Wallarm filtering node image is specified in the Helm chart configuration file → wallarm.image.tag
.
Step 1: Creating Wallarm ConfigMap¶
Go to the Helm chart directory → the templates
folder and create a wallarm-sidecar-configmap.yaml
template with the following content:
apiVersion: v1
kind: ConfigMap
metadata:
name: wallarm-sidecar-nginx-conf
data:
default: |
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
server_name localhost;
root /usr/share/nginx/html;
index index.html index.htm;
wallarm_mode {{ .Values.wallarm.mode | quote }};
# wallarm_application 1;
set_real_ip_from 0.0.0.0/0;
real_ip_header X-Forwarded-For;
location / {
proxy_pass http://localhost:{{ .Values.wallarm.app_container_port }};
include proxy_params;
}
}
Step 2: Updating the Deployment object in Kubernetes¶
-
Return to the Helm chart directory → the
templates
folder and open the template defining theDeployment
object for the application. A complex application can have severalDeployment
objects for different components of the application - please find an object which defines pods which are actually exposed to the Internet. For example:apiVersion: apps/v1 kind: Deployment metadata: name: myapp spec: selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: # Definition of your main app container - name: myapp image: <Image> resources: limits: memory: "128Mi" cpu: "500m" ports: # Port on which the application container accepts incoming requests - containerPort: 8080
-
Copy the following elements to the template:
- The
checksum/config
annotation to thespec.template.metadata.annotations
section to update the running pods after a change in the previously created ConfigMap object - The
wallarm
sidecar container definition to thespec.template.spec.containers
section - The
wallarm-nginx-conf
volume definition to thespec.template.spec.volumes
section
An example of the template with added elements is provided below. Elements for copying are indicated by the
Wallarm element
comment.apiVersion: apps/v1 kind: Deployment metadata: annotations: # Wallarm element: annotation to update running pods after changing Wallarm ConfigMap checksum/config: '{{ include (print $.Template.BasePath "/wallarm-sidecar-configmap.yaml") . | sha256sum }}' name: myapp spec: selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: # Wallarm element: definition of Wallarm sidecar container - name: wallarm image: {{ .Values.wallarm.image.repository }}:{{ .Values.wallarm.image.tag }} imagePullPolicy: {{ .Values.wallarm.image.pullPolicy | quote }} env: - name: WALLARM_API_HOST value: {{ .Values.wallarm.wallarm_host_api | quote }} - name: DEPLOY_USER value: {{ .Values.wallarm.deploy_username | quote }} - name: DEPLOY_PASSWORD value: {{ .Values.wallarm.deploy_password | quote }} - name: DEPLOY_FORCE value: "true" - name: TARANTOOL_MEMORY_GB value: {{ .Values.wallarm.tarantool_memory_gb | quote }} ports: - name: http # Port on which the Wallarm sidecar container accepts requests # from the Service object containerPort: 80 volumeMounts: - mountPath: /etc/nginx/sites-enabled readOnly: true name: wallarm-nginx-conf # Definition of your main app container - name: myapp image: <Image> resources: limits: memory: "128Mi" cpu: "500m" ports: # Port on which the application container accepts incoming requests - containerPort: 8080 volumes: # Wallarm element: definition of the wallarm-nginx-conf volume - name: wallarm-nginx-conf configMap: name: wallarm-sidecar-nginx-conf items: - key: default path: default
- The
-
Update the
ports.containerPort
value in sidecar container definition following the code comments.
Step 3: Updating the Service object in Kubernetes¶
-
Return to the Helm chart directory → the
templates
folder and open the template defining theService
object that points toDeployment
modified in the previous step. For example: -
Change the
ports.targetPort
value to point to the Wallarm sidecar container port (ports.containerPort
defined in the Wallarm sidecar container). For example:
Step 4: Updating the Helm chart configuration file¶
-
Return to the Helm chart directory and open the
values.yaml
file. -
Copy the
wallarm
object definition provided below tovalues.yaml
and update parameter values following the code comments.wallarm: image: repository: wallarm/node tag: 3.6.2-1 pullPolicy: Always # Wallarm API endpoint: # "api.wallarm.com" for the EU Cloud # "us1.api.wallarm.com" for the US Cloud wallarm_host_api: "api.wallarm.com" # Username of the user with the Deploy role deploy_username: "username" # Password of the user with the Deploy role deploy_password: "password" # Port on which the container accepts incoming requests, # the value must be identical to ports.containerPort # in definition of your main app container app_container_port: 80 # Request filtration mode: # "off" to disable request processing # "monitoring" to process but not block requests # "safe_blocking" to block malicious requests originated from graylisted IPs # "block" to process all requests and block the malicious ones mode: "block" # Amount of memory in GB for request analytics data tarantool_memory_gb: 2
-
Make sure the
values.yaml
file is valid using the following command: -
Deploy the modified Helm chart in the Kubernetes cluster using the following command:
<RELEASE>
is the name of an existing Helm chart<CHART>
is the path to the Helm chart directory
NetworkPolicy object in Kubernetes
If the application also uses the NetworkPolicy
object it should be updated to reflect the Wallarm sidecar container port specified above.
Step 5: Testing the Wallarm sidecar container¶
-
Get the list of pods using the following command:
The number of containers in the pod should increase, and the status of the pod should be Running.
-
Go to Wallarm Console → Nodes via the link below and make sure that a new node is displayed. This created node is used to filter requests to your application.
-
Send a test malicious request to the application as described in these instructions.
-
Go to Wallarm Console → Attacks via the link below and make sure that an attack is displayed in the list: