📝 PREVIEW This post is not yet public. It will go live on Wed 15 Jul 2026, 09:00 IST. Public URL: /blog/fortiweb-kubernetes-container-2026

Back to Blog

FortiWeb in Kubernetes and container environments

Published 15 Jul 2026 · By Pawan Sharma · Cloud Security · 13 min read

Kubernetes apps don't stop being apps. The OWASP Top 10 still applies; APIs still need schema enforcement; bots still scrape. What changes is how the WAF deploys. FortiWeb Container is the shape Fortinet ships for Kubernetes / Docker environments — sidecar or ingress integration, CI/CD-aligned policy, continuous-learning ML that adapts when a deployment rolls. This guide walks the deployment patterns + the integration story.

Container

5th shape

Listed alongside HW / VM / Cloud / SaaS in the Ordering Guide.

CI/CD ✓

Continuous Learning

Policy adapts to app updates without manual rewrite.

Helm

Deployment

Standard Helm chart. GitOps-compatible policy export/import via REST.

FortiManager

Multi-cluster

One pane across container + VM + HW + FortiAppSec estates.

Two deployment patterns

Ingress pattern (north-south)

FortiWeb Container as cluster ingress controller
External traffic enters via FortiWeb pod before hitting any app
One FortiWeb deployment per cluster (sized to peak traffic)
Standard pattern — most enterprises start here
Simpler operational model
Policy refresh tied to cluster ingress changes

Sidecar pattern (east-west)

FortiWeb Container as sidecar per app pod
Inspects service-to-service traffic inside the mesh
One FortiWeb container per app pod
Higher policy depth; higher operational overhead
Best for high-security microservice estates
Per-service policy granularity

What the Ordering Guide says

Per FortiWeb Ordering Guide (FWEB-OG-R25-20260318)

"HW/VM/container: models range from 50 Mbps to 70 Gbps throughput. BYOL/PAYG for VMs deployed on public cloud."

Container is the 5th deployment shape alongside Appliance, Virtual Machine, Cloud, and SaaS. The Container line is explicitly designed for CI/CD-pipeline integration: "Continuous Learning automatically adjusts models when application changes, virtually integrating with CI/CD pipeline."

How it integrates — the CI/CD-aligned story

▸ Schema-driven policy

OpenAPI / Swagger schemas exported from your API gateway feed FortiWeb's positive-security model. Policy is generated from the schema; schema lives alongside app code.

▸ Pipeline-pushed policy

FortiWeb REST API endpoints allow policy push from CI/CD. Standard pattern: schema update in repo → policy regenerate in pipeline → push to FortiWeb at deployment time.

▸ Continuous Learning

ML model adapts the behavioural baseline as the app evolves. New endpoint in a deployment? Model learns it from traffic, schema, or both. No manual rewrite when the app changes.

▸ Helm chart deployment

Standard Helm chart. values.yaml controls FortiWeb mode (monitor / enforce), ingress class binding, replicas, CPU / memory requests.

▸ GitOps-compatible

Policy YAML lives in your repo alongside app manifests. Pipeline pushes policy updates with each release. No drift between code and WAF policy.

▸ Multi-cluster via FortiManager

One FortiManager pushes policy to FortiWeb Containers across N clusters. Multi-region, multi-cloud, multi-cluster — single pane.

Architecture patterns by app type

App type	Recommended pattern	Why
Single-team microservice estate	Ingress controller	Simplest operational model; one FortiWeb per cluster
Multi-team / multi-tenant cluster	Ingress + per-team policy	Single FortiWeb, namespace-scoped policy
Zero-trust microservice estate	Sidecar per pod	East-west inspection between services
Hybrid: K8s app + non-K8s app	Container + VM-S BYOL	Same FortiManager / FortiAnalyzer plane
K8s + Istio mesh	FortiWeb at ingress; Istio mTLS inside	Layer separation: WAF policy on FortiWeb, mTLS on Istio

A typical deployment week

Day 1 — Helm install + policy import

FortiWeb Container Helm chart installs to a dedicated namespace. Initial OpenAPI schema imported. Monitor mode.

Day 2-3 — Wire to ingress

Bind FortiWeb as the cluster ingress controller (or as ingress class for specific namespaces). Verify traffic flow + log forwarding to FortiAnalyzer.

Day 4-5 — ML baseline + tuning

Continuous-learning model builds the behavioural baseline. Review false-positive candidates. Tune signature thresholds.

Day 6-7 — Enforce on first endpoint

Flip enforce on the lowest-risk endpoint (eg health check, public docs). Watch for 24 hours. Roll back if needed.

Week 2 — Hook into CI/CD pipeline

Wire schema regeneration into your release pipeline. Future deployments auto-push schema updates to FortiWeb. Continuous Learning takes over for drift.

FortiWeb Container vs running FortiWeb-VM next to K8s

FortiWeb-VM outside K8s

VM sits in front of K8s cluster's LB / ingress
Standard VM operations
Less integrated with K8s lifecycle
Policy not tied to deployment
Easier if team isn't K8s-native

FortiWeb Container inside K8s

Native K8s ingress controller
Helm-deployed, GitOps-compatible
Continuous-learning policy aligned to releases
Lifecycle managed via K8s
Best for K8s-native teams

FAQ

Sidecar or ingress controller — which pattern?

Ingress for north-south WAF protection (external traffic into the cluster); sidecar for service-to-service inspection (east-west). Most enterprises start with ingress. Sidecar adds policy depth at the cost of operational overhead per pod.

Does FortiWeb Container support Istio / service-mesh?

Yes — FortiWeb Container can run alongside Istio. Istio handles routing + mTLS; FortiWeb handles WAF policy. Standard pattern: FortiWeb at ingress; Istio inside the mesh.

How does Continuous Learning work for container WAF?

The ML model trained on the application's traffic adapts to changes pushed via CI/CD. New endpoints in a deployment trigger schema refresh; the model rebuilds its baseline without manual intervention. This is the key differentiator vs static-policy WAFs in CI/CD-fast environments.

Can FortiWeb Container be configured via Helm chart?

Yes. Standard Helm chart deployment; values.yaml controls policy mode, ingress class, replicas, resource limits. Ogma can deploy via your existing CI/CD pipeline.

What about WAF policy in GitOps workflows?

FortiWeb policy can be exported/imported via REST API, which fits GitOps patterns. Policy YAML stored alongside app manifests; deployment pipeline pushes policy updates as part of release.

Performance overhead — what should we plan for?

Resource sizing is documented per FortiWeb Container CPU/memory request. Plan for ~10-15% overhead on application pods when sidecar deployed; ingress-mode adds dedicated FortiWeb pods sized to traffic volume.

Does FortiWeb Container integrate with FortiAnalyzer?

Yes — logs forward to FortiAnalyzer (cloud or on-prem) the same as appliance / VM-S shapes. Centralised logging across container + VM + HW + FortiAppSec estates.

Multi-cluster — single policy plane?

FortiManager pushes policy to FortiWeb Containers across multiple clusters. Same management plane as appliance / VM-S. Multi-cluster Kubernetes estates use the same FortiManager workflow as multi-DC HW deployments.

Free FortiWeb K8s pilot scoping

Sized deployment plan for your specific cluster + CI/CD

Ogma scopes the right deployment pattern (ingress / sidecar / hybrid), sizes resource requests, designs the CI/CD hook for policy refresh, and returns a 2-week pilot plan.

Request the pilot scoping or explore FortiWeb API Security

Sources

FortiWeb Ordering Guide (FWEB-OG-R25-20260318) — Container as 5th deployment shape
FortiWeb Data Sheet — Continuous Learning, CI/CD integration

Tags Fortinet FortiWeb WAF Kubernetes Container DevSecOps CI/CD India

Stay ahead of cyber threats

One short email a week — curated Indian cybersecurity news, Fortinet releases, DPDPA updates. No fluff.

FortiWeb in Kubernetes and container environments