Deploying the Native Node with Helm Chart¶

The Wallarm Native Node, which operates independently of NGINX, is designed for deployment with some connectors. You can run the Native Node on as a separate service or as a load balancer in your Kubernetes cluster using the Helm chart.

Use cases¶

Deploy the Native Node with Helm chart in the following cases:

When you deploy a Wallarm connector for MuleSoft, Cloudflare, Amazon CloudFront, Broadcom Layer7 API Gateway, Fastly and require the node to be self-hosted. This is ideal if you are already using Kubernetes management platforms like OpenShift, Amazon EKS, Azure AKS, or Google GKE. The node is set up as a load balancer with a public IP for easy traffic routing.
When you deploy a Wallarm connector for Kong API Gateway or Istio. The node is deployed with the clusterIP type for internal traffic, without exposing a public IP.

Requirements¶

The Kubernetes cluster for deploying the Native Node with the Helm chart must meet the following criteria:

Helm v3 package manager installed.
Inbound access from your API gateway or CDN where your APIs are running.
Outbound access to:
- https://charts.wallarm.com to download the Wallarm Helm chart
- https://hub.docker.com/r/wallarm to download the Docker images required for the deployment
- https://us1.api.wallarm.com or https://api.wallarm.com for US/EU Wallarm Cloud
- IP addresses below for downloading updates to attack detection rules and API specifications, as well as retrieving precise IPs for your allowlisted, denylisted, or graylisted countries, regions, or data centers
  US CloudEU Cloud
  34.96.64.17 34.110.183.149 35.235.66.155 34.102.90.100 34.94.156.115 35.235.115.105
  34.160.38.183 34.144.227.90 34.90.110.226
If deploying with the LoadBalancer type, you need a domain and a trusted SSL/TLS certificate.
In addition to the above, you should have the Administrator role assigned in Wallarm Console.

Limitations¶

When deploying the Wallarm service with the LoadBalancer type, a trusted SSL/TLS certificate is required for the domain. Self-signed certificates are not yet supported.
Custom blocking page and blocking code configurations are not yet supported.
Rate limiting by the Wallarm rule is not supported.
Multitenancy is not supported yet.

Deployment¶

1. Prepare Wallarm token¶

To install node, you will need a token for registering the node in the Wallarm Cloud. To prepare a token:

Open Wallarm Console → Settings → API tokens in the US Cloud or EU Cloud.
Find or create API token with the Deploy source role.
Copy this token.

2. Add the Wallarm Helm chart repository¶

helm repo add wallarm https://charts.wallarm.com
helm repo update wallarm

3. Prepare the configuration file¶

LoadBalancerClusterIP

Deploying the native Wallarm node as a LoadBalancer with a public IP allows you to route traffic from MuleSoft, Cloudflare, Amazon CloudFront, Broadcom Layer7 API Gateway, Fastly to this IP for security analysis and filtration.

Register a domain for the load balancer.
Obtain a trusted SSL/TLS certificate.

Create the values.yaml configuration file with the following minimal configuration. Choose the tab for your preferred method of applying the certificate:

cert-managerexistingSecretcustomSecret

If you use cert-manager in your cluster, you can generate the SSL/TLS certificate with it.

config:
  connector:
    certificate:
      enabled: true
      certManager:
        enabled: true
        issuerRef:
          # The name of the cert-manager Issuer or ClusterIssuer
          name: letsencrypt-prod
          # If it is Issuer (namespace-scoped) or ClusterIssuer (cluster-wide)
          kind: ClusterIssuer
processing:
  service:
    type: LoadBalancer

You can pull SSL/TLS certificate from an existing Kubernetes secrets in the same namespace.

config:
  connector:
    certificate:
      enabled: true
      existingSecret:
        enabled: true
        # The name of the Kubernetes secret containing the certificate and private key
        name: my-secret-name
processing:
  service:
    type: LoadBalancer

The customSecret configuration allows you to define a certificate directly as base64-encoded values.

config:
  connector:
    certificate:
      enabled: true
      customSecret:
        enabled: true
        ca: LS0...  # Base64-encoded CA
        crt: LS0... # Base64-encoded certificate
        key: LS0... # Base64-encoded private key
processing:
  service:
    type: LoadBalancer

When deploying Wallarm as a connector for Kong API Gateway or Istio you deploy the Native Node for this connector with the ClusterIP type for internal traffic, without exposing a public IP.

Create the values.yaml configuration file with the following minimal configuration:

processing:
  service:
    type: ClusterIP

All configuration parameters

4. Deploy the Wallarm service¶

US CloudEU Cloud

helm upgrade --install --version 0.12.1 <WALLARM_RELEASE_NAME> wallarm/wallarm-node-native -n wallarm-node --create-namespace --set config.api.token=<WALLARM_API_TOKEN> --set config.api.host=us1.api.wallarm.com

helm upgrade --install --version 0.12.1 <WALLARM_RELEASE_NAME> wallarm/wallarm-node-native -n wallarm-node --create-namespace --set config.api.token=<WALLARM_API_TOKEN> --set config.api.host=api.wallarm.com

5. Get the Wallarm load balancer¶

If deploying with the LoadBalancer type:

Get the external IP for the Wallarm load balancer:
```
kubectl get svc -n wallarm-node
```
Find the external IP for the native-processing service.
Create an A record in your DNS provider, pointing your domain to the external IP.

After the DNS propagates, you can access the service via the domain name.

6. Apply Wallarm code to an API management service¶

After deploying the node, the next step is to apply the Wallarm code to your API management platform or service in order to route traffic to the deployed node.

Contact sales@wallarm.com to obtain the Wallarm code bundle for your connector.
Follow the platform-specific instructions to apply the bundle on your API management platform:

Upgrade¶

To upgrade the node, follow the instructions.