Installing Wallarm from App Templates

Wallarm application firewall (WAF) #

Wallarm Application Firewall provides API security capabilities to protect your entire portfolio of APIs. It provides protection from:

• API abuse
• API leaks
• Web attacks
• API attacks
• Bots
• Issues and misconfigurations

It combines API discovery, risk management, real-time protection, and testing with advanced API security capabilities.

Wallarm can be seamlessly integrated into a Kubernetes cluster using multiple approaches:

• Deploying NGINX Ingress Controller with integrated Wallarm services
• Deploying with NGINX using ingress controller chaining
• Deploying as a sidecar alongside application pods
• Wallarm eBPF-based solution

Wallarm node token #

Wallarm nodes are proxies deployed in a customer environment that mitigate malicious requests and forward legitimate requests to the customer application.

Kosmos provides a convenient installation method for the Wallarm node proxy.

The Wallarm node requires an API token provided by the Wallarm dashboard to authenticate with the hosted Wallarm service.

Steps to obtain node api token #

1. Navigate to Wallarm Dashboard
2. Navigate to Settings
3. Navigate to API tokens
4. Select Create token
5. Create a token for Node deployment
6. Populate remaining fields as appropriate

Below is a screenshot of this form:

Click Create and store the generated token securely.

Note: If the token is lost, it can be copied again using the ellipsis menu for the token.

Kosmos app template #

Apps in the Kosmos platform allow administrators to package applications and scripts into consumable deployment units.

Apps can be:

• Existing or custom (user provided) Helm charts
• Kubernetes manifests
• Bash scripts installing resources into clusters or virtual clusters

Apps may also contain parameters allowing users to customize deployments.

Kosmos provisioning of wallarm app template #

This document explains Approach 1:

Deploying NGINX Ingress Controller with Integrated Wallarm Services using the Wallarm App Template in a Fleet cluster.

Note #

• Wallarm AppTemplate can be installed only in Fleet Clusters and not in virtual clsuter
• Installation in Virtual Clusters is blocked by Kyverno policies
• This restriction has been added to avoid creation of Load Balancer services, which results in to leakage of resources.

Steps to install wallarm as app template #

Connect to cluster #

Download the kubeconfig and set the path into KUBECONFIG environment variable:

export KUBECONFIG=<path-to-kubeconfig>

Prequisites #

Create namespace using CLI #

Create a namespace for Wallarm installation:

kubectl create namespace wallarm-ingress

Example output:

namespace/wallarm-ingress created

Verify:

kubectl get namespaces

Example output:

NAME              STATUS   AGE
default           Active   3m15s
kube-node-lease   Active   3m15s
kube-public       Active   3m15s
kube-system       Active   3m15s
wallarm-ingress   Active   15s

Create wallarm api token secret using CLI #

Create a Kubernetes secret containing the Wallarm API token.

kubectl create secret generic wallarm-token \
  --from-literal=token=<YOUR_WALLARM_TOKEN_HERE> \
  -n wallarm-ingress

Example output:

secret/wallarm-token created

Install app from Kosmos Managment Console #

1. Navigate to Fleet Cluster → Apps

   

2. Click Install App

3. Search for Wallarm Ingress

4. Keep:

   • Namespace (default)
   • Secret name (wallarm-token)

   

5. Click Install

A popup confirming installation request appears.

Close the popup once deployment completes.

Installed resources #

The Wallarm App installation creates multiple resources inside the Fleet Cluster.

These resources are visible under the Resources tab.

Note:

• The wallarm-token secret should be manually created before installation.
• The screenshots below depict resources created during installation.

Note: The “wallarm-token” secret in the above screenshot is created by the user manually, before installing the Wallarm apptemplate.

Enabling traffic analysis #

To enable traffic analysis:

Annotate the application ingress resource.

Once completed without errors, the setup is finished.

For details refer to Enabling traffic analysis for your ingress

Installing sample application and enabling traffic analysis using Wallarm #

NOTE: This section demonstrates Wallarm traffic analysis using a sample application and is optional.

Wallarm protects APIs exposed by applications/services.

Preparing for secured api #

Create self-signed certificate:

For creating a self-signed certificate, one can use the following script, which creates CA certificate and a certificate signed by the former certificate.

#! /bin/bash

# reference: https://devopscube.com/create-self-signed-certificates-openssl/

if [ "$#" -ne 3 ]
then
  echo "Error: No domain name argument provided"
  echo "Usage: Provide a domain name, org, and org unit as arguments"
  exit 1
fi

DOMAIN=$1
ORG=$2
ORG_UNIT=$3

# Create root CA & Private key

openssl req -x509 \
            -sha256 -days 356 \
            -nodes \
            -newkey rsa:2048 \
            -subj "/CN=${DOMAIN}/C=US/L=San Fransisco" \
            -keyout rootCA.key -out rootCA.crt

# Generate Private key

openssl genrsa -out ${DOMAIN}.key 2048

# Create csf conf

cat > csr.conf <<EOF
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[ dn ]
C = US
ST = California
L = San Fransisco
O = ${ORG}
OU = ${ORG_UNIT}
CN = ${DOMAIN}

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = ${DOMAIN}
DNS.2 = www.${DOMAIN}
IP.1 = 192.168.1.5
IP.2 = 192.168.1.6

EOF

# create CSR request using private key

openssl req -new -key ${DOMAIN}.key -out ${DOMAIN}.csr -config csr.conf

# Create a external config file for the certificate

cat > cert.conf <<EOF

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = ${DOMAIN}

EOF

# Create SSl with self signed CA

openssl x509 -req \
    -in ${DOMAIN}.csr \
    -CA rootCA.crt -CAkey rootCA.key \
    -CAcreateserial -out ${DOMAIN}.crt \
    -days 365 \
    -sha256 -extfile cert.conf

And run the above shell script, with DOMAIN, ORG, and ORG Unit as parameters. For my certificate, i used the following command:

ssl.sh httpbin.local local httpbin

Create kubernetes secret #

Create a Kubernetes TLS secret using the generated certificate and key.

Run the following command:

kubectl create secret tls httpbin-local.secret --cert=./httpbin.local.crt --key=./httpbin.local.key -o yaml > httpbin-local.secret

Apply the generated secret to your cluster

kubectl apply -f httpbin-local.secret

Install httpbin application #

The httpbin application is used as a sample API service to demonstrate Wallarm traffic analysis.

Clone the helm chart #

git clone https://github.com/wklken/httpbin-chart.git
cd httpbin-chart

Configure ingress and tls #

Edit the values.yaml file and update the ingress configuration as shown below:

ingress:
  enabled: true
  className: "nginx"
  annotations: {}
  hosts:
    - host: httpbin.local
      paths:
        - path: /
          pathType: ImplementationSpecific
  tls:
    - secretName: httpbin-local.secret
      hosts:
        - httpbin.local

Install the chart #

Install the application using Helm:

helm install httpbin .

After installation:

• httpbin is deployed in the default namespace
• Wallarm components run in the wallarm-ingress namespace
• Application and ingress pods should now be running successfully

Annotate application for Wallarm traffic analysis #

To enable Wallarm traffic inspection, annotate the application ingress resource.

Assuming httpbin is deployed in the default namespace, run:

kubectl annotate ingress httpbin -n default \
  nginx.ingress.kubernetes.io/wallarm-mode=monitoring

kubectl annotate ingress httpbin -n default \
  nginx.ingress.kubernetes.io/wallarm-application="<APPLICATION_ID>"

Verify that the ingress resource is successfully annotated before proceeding.

Verify the WAF setup #

Retrieve the external ingress address and test application access using curl.

curl -kv https://<ingress_external_address> \
  -H "HOST: httpbin.local" \
  -H "accept: application/json"

Expected result #

• TLS connection succeeds
• Application returns a valid response
• Request is allowed by the Wallarm firewall

Example ingress log:

HTTP/2.0" 200

This confirms that legitimate traffic is successfully processed.

Test malicious request blocking #

To validate WAF protection, simulate a malicious request attempting path traversal by accessing the /etc/passwd:

curl -kv https://<ingress_external_address>/etc/passwd \
  -H "HOST: httpbin.local" \
  -H "accept: application/json"

Expected result #

The request should return:

403 Forbidden

This indicates that:

• The Wallarm ingress controller intercepted the request
• Malicious traffic was blocked before reaching the application

Example Wallarm ingress controller log:

GET /etc/passwd HTTP/2.0" 403

Verify attack event in Wallarm UI #

Navigate to the Attacks section in the Wallarm Console.

A path traversal attack event should appear displaying:

• Source IP address
• Application annotation ID
• Attack classification details

This confirms that Wallarm traffic analysis and protection are functioning correctly.

Additional references #

• Wallarm Documentation — Deployment
• Wallarm Documentation — All Deployment Options
• How To Configure Ingress TLS/SSL Certificates in Kubernetes

Edit this page on GitHub