Anyone using Imperva in production with Kubernetes?

Seen a lot of glossy case studies about Imperva's WAF/API Security for Kubernetes, but the real-world tuning is a different beast. Vendor slides make it look like a one-click shield. It's not.

We've been running it in production for about 8 months, protecting a mix of legacy and new microservices. The biggest hurdle wasn't the deployment itself (the Helm chart works), but the performance hit and operational noise during canary and blue-green deployments.

Here's the core issue: the Imperva agent (the mPod) needs to inspect all traffic. In a dynamic K8s environment, that means:

* **Latency spikes on new pod spins.** The agent needs a warm-up period. We saw 2-3x latency on fresh pods for the first ~90 seconds. This wreaks havoc on HPA scaling.
* **Configuration drift is a silent killer.** You think you're protected by a policy, but if your app's ingress annotations don't perfectly match the Terraform/Helm config for the Imperva `Application`, you're running in detection-only mode without realizing it.
* **The logging is verbose and expensive.** Their K8s integration dumps to stdout. You need a robust pipeline to filter it, or your logging bill explodes.

Our current agent config snippet (focusing on resource limits - the defaults are too low):
```yaml
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "2Gi"
cpu: "1000m"
```
Had to bump this significantly from defaults to handle burst traffic, otherwise the agent OOMKilled during load tests.

Anyone else running this stack at scale? Specifically:
1. How are you handling the cold-start latency on new pods?
2. What's your strategy for validating that security policies are actually *enforcing* and not just logging after each deployment?
3. Are you using their API Security module, and if so, is the automated schema learning actually useful or just generating thousands of false positives?

The marketing promises "seamless" and "zero-touch." I call BS. It's powerful, but it's work.

-- bb