Description
## Let’s Talk About Where Your APIs Actually Run
**Quick answer:** On-premises API security keeps API discovery, detection, and enforcement inside your own perimeter instead of a third-party cloud—the model regulated industries need. Deploying it natively on Kubernetes (sidecar sensors → a discovery controller → an inline WAF gateway) makes it practical: continuous API discovery surfaces shadow and zombie endpoints, behavioral detection catches API-specific threats like BOLA, and the WAF blocks them in real time.
Most security teams already know they need API discovery, including east-west traffic between internal services. That conversation has largely won. The harder question is: where do you actually deploy your API security solution?
For organizations in regulated industries, such as banks, healthcare systems, defense contractors, the answer isn't straightforward. Data sovereignty requirements, compliance mandates, and network restrictions often rule out cloud-hosted security services. Your APIs run on-prem, so your API security has to run there too.
I spent years in application security before moving into product management, and one pattern kept repeating. Security teams have traditionally relied on preproduction security scanning and testing, which works well for known endpoints but inherently misses runtime security abuses, the shadow APIs, the undocumented endpoints, the services that only reveal their risk under live traffic. The coverage gap wasn't a technology problem it was a deployment problem. The security tooling wasn't running where the APIs were running.
That's the problem this article is about. Not whether you need API security, you do. But how and where you deploy it, so it covers your full environmentAnd increasingly, the answer is Kubernetes.
## The API Security Gap That Nobody Wants to Admit
Once you've decided to deploy on-prem, the first thing that becomes clear is just how much of your API footprint was previously unaccounted for.
In my experience working with customers, teams often start out believing they have around 50 or 60 API endpoints. Once automated discovery runs against live traffic, that number frequently jumps to 300+. It's not that anything was done wrong — those extra 240+ endpoints simply weren't in any documentation or Swagger file. They were built for legitimate reasons, serving real traffic in production, but had never gone through a formal security review.
The real value of discovery is surfacing these blind spots not to assign blame, but to give security teams complete visibility so they can protect the full attack surface, not just the parts they already knew about.
### Why Deployment Location Changes Everything
When API security runs externally or as a periodic exercise, you're dependent on someone compiling a list of endpoints before anything gets scanned. That's not a people's failure it's an architectural one. The security tooling isn't sitting where the traffic flows, so it can only see what it's told about.
Engineers focus on what they’re actively building. The endpoint they created eight months ago for a partner POC that never went anywhere? It’s not on their radar. The internal debugging endpoint that was supposed to be temporary? Still running. The v1 of an API that was “replaced” by v2 but never actually decommissioned? Still accepting requests.
The security team scans what they’re given. The audit report comes back clean. And everyone moves on, not realizing that the scan only covers 30% of the actual attack surface.
### WAFs Are Essential but They Need the Right Intelligence
WAFs are the enforcement backbone. They sit inline, they can block traffic, and they’re battle-tested. That’s exactly what you want to stop threats in real time. The challenge isn’t the WAF itself; it’s what the WAF knows about.
A WAF is incredibly effective when it knows what to look for and where to look. But traditional WAF deployments rely on rules and signatures of SQL injection patterns, XSS payloads, and malformed requests. API-specific threats like BOLA (Broken Object-Level Authorization) don’t match those patterns. An attacker changes an object’s ID to access someone else’s data, and the request looks perfectly normal. Well-formed, authenticated, and syntactically valid. The WAF has no reason to flag it because it doesn’t have the API-level context to know that request shouldn’t be accessing that resource.
That’s where a dedicated API security layer becomes the WAF’s force multiplier. It provides the discovery, the behavioral analysis, and the API-specific threat intelligence. The WAF provides inline enforcement. Together, they form a closed loop: the API security platform detects, the WAF gateway blocks. Neither is complete without the other.
And both can only protect what they can see, which brings us back to why continuous API discovery matters so much. If an endpoint was never registered and never put behind the WAF, it’s completely exposed. Discovery closes that gap.
### The Compliance Clock Is Ticking
This used to be a “nice to have” conversation. It’s not anymore. PCI DSS 4.0.1 now requires continuous API security testing and maintained API inventories. (These PCI DSS 4.0.1 requirements became mandatory on March 31, 2025.) The EU Cyber Resilience Act mandates security testing throughout the development lifecycle. ISO 27001:2022 introduced new application-security controls—including secure coding (A.8.28) and application security requirements (A.8.26)—that apply directly to APIs. If you’re in a regulated industry running on-prem APIs and you don’t have dedicated API security, your next audit is going to be uncomfortable.
## Built for Kubernetes Infrastructure
Modern application environments are increasingly standardizing Kubernetes. It's where workloads run, where infrastructure teams are investing, and where operational tooling is already mature. Our on-prem API security solution is purpose-built to deploy natively on this infrastructure.
Because it runs on Kubernetes, it inherits the operational benefits that teams already rely on pod-level self-healing for high availability, Helm-based deployments for consistent upgrades, and native integration with existing monitoring stacks like Prometheus, Grafana, or the ELK stack. There's no separate HA architecture to build, no custom upgrade orchestration to maintain, and no new observability tooling for your SREs to learn.
For teams already running Kubernetes, adding API security to the cluster is operationally familiar. It fits into the workflows, tooling, and processes your infrastructure team already uses every day
## What the Architecture Actually Looks Like
Here's how architecture works in practice.
### Continuous API Discovery
API discovery works through our lightweight sensors, deployed as Kubernetes sidecars alongside your application pods. These sensors passively mirror API traffic without adding latency or altering request flows and send the metadata to the API Security controller. The controller analyzes this traffic and continuously builds a complete inventory of every API endpoint in your environment, including REST, GraphQL, gRPC, and SOAP.
Because discovery is based on live traffic observation through the sensors rather than static documentation or manual reporting, it surfaces everything shadow APIs that were never documented, zombie endpoints that were supposed to be decommissioned, and internal services that no one remembered to put through a security review.
In my experience working with customers, teams that expected 50 or 60 endpoints routinely discover 300+. The discovery phase alone just seeing what you actually have justified the deployment for a lot of organizations. It's the difference between securing a fraction of your attack surface and securing all of it.
### Classification and Risk Scoring
Not every API carries the same risk. A health-check endpoint and a payment processing API are in different universes from a security standpoint. The platform classifies APIs based on what data they handle PII, financial data, credentials, health records and assigns risk scores. This is what keeps security teams from drowning in alerts. You focus on the endpoints that matter most.
### Detection
The API security platform builds behavioral baselines for API usage and flags deviations. BOLA patterns. Schema violations. Unusual request volumes. Credential stuffing. Authentication anomalies. This is the intelligence layer it understands API-specific threats that signature-based rules alone can’t catch. But intelligence without enforcement is just expensive monitoring. That’s where the WAF gateway comes in.
### Enforcement - The Detection-to-Blocking Loop
This is where our solution stands apart. The API security controller detects threats. The WAF gateway enforces inline. It's a closed loop detection that intelligence feeds directly to the gateway, and the gateway blocks in real time. Neither layer is effective alone. The controller without the gateway can only be alert. The gateway without the controller only has signatures and static rules to work with. Together, you get detection depth and enforcement power.
We are the only solution on the market capable of this level of fine-grained blocking. And by fine-grained, we mean something very specific.
Most competing approaches block at the IP level attacker identified; entire IP blocked. In any real environment, API consumers share IPs constantly. Corporate NAT gateways, CDN exit nodes, partner integrations behind shared proxies. Block one IP and you cut off every legitimate consumer behind that address.
Our enforcement goes well beyond endpoint-level blocking. When the controller detects a threat to say, a BOLA attack doesn't just block the endpoint or the source IP. It pushes a targeted rule to the WAF gateway that blocks the specific request pattern and the specific token involved. That means a malicious actor session gets shut down while other users hitting the same endpoint from the same IP continue uninterrupted. The blocking is surgical scoped to the exact behavior and identity, not the network address or even the endpoint as a whole.
This might sound like a subtle technical distinction, but in production it changes everything. It's the difference between a security tool your operations team is confident turning on and one they keep in monitor-only mode because they're afraid of the blast radius.
## The Conversations This Solves
I’m framing these as actual conversations because that’s how they come up in practice.
**“We don’t know how many APIs we have.”** This is the most common starting point, and continuous discovery closes the gap immediately. Every endpoint serving traffic gets catalogued and classified, whether it’s in your documentation or not.
**“Our WAF handles API security.”** Your WAF is the enforcement engine, and that’s exactly the role it should play. What it needs is the right intelligence to feed it. A dedicated API security layer provides continuous discovery, behavioral analysis, and API-specific threat detection and routes that intelligence to your WAF gateway for inline blocking. Think of it as upgrading your WAF’s awareness, not replacing it.
**“We can’t send traffic to a third-party cloud.”** Then don’t. On-prem deployment keeps everything in traffic analysis, detection, enforcement, and reporting inside your perimeter. This is usually a non-negotiable requirement, not a preference for organizations in regulated industries.
**“We need to prove compliance and we’re running out of time.”** Continuous monitoring produces always-current audit evidence. API inventories, risk classifications, threat logs, and remediation records. It replaces the scramble of point-in-time assessments. I’ve watched teams go from dreading audits to walking in with dashboards. It changes the dynamic completely.
**“Dev ships new APIs every week. Security reviews quarterly.”** That gap is where unprotected APIs live. Automated discovery closes it. New endpoints get monitored the moment they start serving traffic.
## Deployment Is Not the Hard Part
I want to spend a minute on this because there’s a perception that on-prem API security deployment is a multi-week project. In my experience, for teams that already have Kubernetes running, it’s measured in hours.
The typical flow:
1. **Create a namespace** in your existing cluster to isolate the security workload.
2. **Set up a Persistent Volume** 128 GB is a common baseline. This uses whatever storage backend your cluster already supports.
3. **Deploy via Helm.** One command. Configuration goes in a values file. Most solutions follow this model because it’s what Kubernetes teams already know.
4. **Configure traffic ingestion on** how the platform gets visibility into API traffic varies by solution, but the goal is the same: continuous observation of every endpoint in your environment.
5. **Integrate with your inline enforcement layer,** typically your WAF or API gateway. This is what closes the detection-to-enforcement loop, so threats get blocked in real time, not just logged.
Upgrades are the same model. Helm upgrade, new chart version, done.
For a detailed step-by-step installation walkthrough, refer to our deployment guide (available to Imperva customers)
The hard part isn’t deployment. It’s usually an organizational conversation about whether to do it in the first place. Once that decision is made, the technical execution is straightforward.
## Where This Is Heading
API-first architecture isn’t slowing down. If anything, the pace is accelerating in exactly the environments that have the strictest infrastructure constraints of financial services, healthcare, government, critical infrastructure. These organizations need API security that respects their boundaries, not one that asks them to relax those boundaries.
Kubernetes gives you the operational foundation. Purpose-built API security gives you visibility, detection, and enforcement. Together, they deliver a security posture that keeps up with how fast your team ships.
And it all runs inside your own perimeter. Which, for a lot of the teams I work with, is the only answer that matters.
Learn more about Thales’s Imperva unified API security platform.
_API security has moved from “nice to have” to “audit requirement.” If your APIs run on-prem, your security needs to run there too. Kubernetes makes that operationally viable. The question isn’t whether to do it. It’s how soon._
## Frequently Asked Questions
### What is on-premises API security?
On-premises API security runs API discovery, threat detection, and enforcement inside your own data center or private cloud instead of sending traffic to a third-party SaaS. It keeps all API traffic, logs, and analysis within your network perimeter—often a hard requirement for banks, healthcare, government, and other regulated organizations with data-sovereignty and compliance constraints.
### Can you run API security on Kubernetes?
Yes. A Kubernetes-native API security platform deploys as lightweight sidecar sensors next to your application pods, feeding mirrored traffic to a controller that builds a live API inventory across REST, GraphQL, gRPC, and SOAP. Because it runs on Kubernetes, it inherits pod-level high availability, Helm-based upgrades, and integration with monitoring stacks like Prometheus and Grafana—so adding it to an existing cluster typically takes hours, not weeks.
### What is a shadow API?
A shadow API is an endpoint serving live traffic that is not in any documentation, Swagger file, or official inventory—often an old version, partner integration, or internal debugging endpoint that was never decommissioned. Continuous, traffic-based API discovery surfaces shadow (and “zombie”) APIs so security teams can protect the full attack surface, not just the endpoints they already know about.
The post On-Premises API Security on Kubernetes: What It Actually Looks Like in Practice appeared first on Blog.
**Quick answer:** On-premises API security keeps API discovery, detection, and enforcement inside your own perimeter instead of a third-party cloud—the model regulated industries need. Deploying it natively on Kubernetes (sidecar sensors → a discovery controller → an inline WAF gateway) makes it practical: continuous API discovery surfaces shadow and zombie endpoints, behavioral detection catches API-specific threats like BOLA, and the WAF blocks them in real time.
Most security teams already know they need API discovery, including east-west traffic between internal services. That conversation has largely won. The harder question is: where do you actually deploy your API security solution?
For organizations in regulated industries, such as banks, healthcare systems, defense contractors, the answer isn't straightforward. Data sovereignty requirements, compliance mandates, and network restrictions often rule out cloud-hosted security services. Your APIs run on-prem, so your API security has to run there too.
I spent years in application security before moving into product management, and one pattern kept repeating. Security teams have traditionally relied on preproduction security scanning and testing, which works well for known endpoints but inherently misses runtime security abuses, the shadow APIs, the undocumented endpoints, the services that only reveal their risk under live traffic. The coverage gap wasn't a technology problem it was a deployment problem. The security tooling wasn't running where the APIs were running.
That's the problem this article is about. Not whether you need API security, you do. But how and where you deploy it, so it covers your full environmentAnd increasingly, the answer is Kubernetes.
## The API Security Gap That Nobody Wants to Admit
Once you've decided to deploy on-prem, the first thing that becomes clear is just how much of your API footprint was previously unaccounted for.
In my experience working with customers, teams often start out believing they have around 50 or 60 API endpoints. Once automated discovery runs against live traffic, that number frequently jumps to 300+. It's not that anything was done wrong — those extra 240+ endpoints simply weren't in any documentation or Swagger file. They were built for legitimate reasons, serving real traffic in production, but had never gone through a formal security review.
The real value of discovery is surfacing these blind spots not to assign blame, but to give security teams complete visibility so they can protect the full attack surface, not just the parts they already knew about.
### Why Deployment Location Changes Everything
When API security runs externally or as a periodic exercise, you're dependent on someone compiling a list of endpoints before anything gets scanned. That's not a people's failure it's an architectural one. The security tooling isn't sitting where the traffic flows, so it can only see what it's told about.
Engineers focus on what they’re actively building. The endpoint they created eight months ago for a partner POC that never went anywhere? It’s not on their radar. The internal debugging endpoint that was supposed to be temporary? Still running. The v1 of an API that was “replaced” by v2 but never actually decommissioned? Still accepting requests.
The security team scans what they’re given. The audit report comes back clean. And everyone moves on, not realizing that the scan only covers 30% of the actual attack surface.
### WAFs Are Essential but They Need the Right Intelligence
WAFs are the enforcement backbone. They sit inline, they can block traffic, and they’re battle-tested. That’s exactly what you want to stop threats in real time. The challenge isn’t the WAF itself; it’s what the WAF knows about.
A WAF is incredibly effective when it knows what to look for and where to look. But traditional WAF deployments rely on rules and signatures of SQL injection patterns, XSS payloads, and malformed requests. API-specific threats like BOLA (Broken Object-Level Authorization) don’t match those patterns. An attacker changes an object’s ID to access someone else’s data, and the request looks perfectly normal. Well-formed, authenticated, and syntactically valid. The WAF has no reason to flag it because it doesn’t have the API-level context to know that request shouldn’t be accessing that resource.
That’s where a dedicated API security layer becomes the WAF’s force multiplier. It provides the discovery, the behavioral analysis, and the API-specific threat intelligence. The WAF provides inline enforcement. Together, they form a closed loop: the API security platform detects, the WAF gateway blocks. Neither is complete without the other.
And both can only protect what they can see, which brings us back to why continuous API discovery matters so much. If an endpoint was never registered and never put behind the WAF, it’s completely exposed. Discovery closes that gap.
### The Compliance Clock Is Ticking
This used to be a “nice to have” conversation. It’s not anymore. PCI DSS 4.0.1 now requires continuous API security testing and maintained API inventories. (These PCI DSS 4.0.1 requirements became mandatory on March 31, 2025.) The EU Cyber Resilience Act mandates security testing throughout the development lifecycle. ISO 27001:2022 introduced new application-security controls—including secure coding (A.8.28) and application security requirements (A.8.26)—that apply directly to APIs. If you’re in a regulated industry running on-prem APIs and you don’t have dedicated API security, your next audit is going to be uncomfortable.
## Built for Kubernetes Infrastructure
Modern application environments are increasingly standardizing Kubernetes. It's where workloads run, where infrastructure teams are investing, and where operational tooling is already mature. Our on-prem API security solution is purpose-built to deploy natively on this infrastructure.
Because it runs on Kubernetes, it inherits the operational benefits that teams already rely on pod-level self-healing for high availability, Helm-based deployments for consistent upgrades, and native integration with existing monitoring stacks like Prometheus, Grafana, or the ELK stack. There's no separate HA architecture to build, no custom upgrade orchestration to maintain, and no new observability tooling for your SREs to learn.
For teams already running Kubernetes, adding API security to the cluster is operationally familiar. It fits into the workflows, tooling, and processes your infrastructure team already uses every day
## What the Architecture Actually Looks Like
Here's how architecture works in practice.
### Continuous API Discovery
API discovery works through our lightweight sensors, deployed as Kubernetes sidecars alongside your application pods. These sensors passively mirror API traffic without adding latency or altering request flows and send the metadata to the API Security controller. The controller analyzes this traffic and continuously builds a complete inventory of every API endpoint in your environment, including REST, GraphQL, gRPC, and SOAP.
Because discovery is based on live traffic observation through the sensors rather than static documentation or manual reporting, it surfaces everything shadow APIs that were never documented, zombie endpoints that were supposed to be decommissioned, and internal services that no one remembered to put through a security review.
In my experience working with customers, teams that expected 50 or 60 endpoints routinely discover 300+. The discovery phase alone just seeing what you actually have justified the deployment for a lot of organizations. It's the difference between securing a fraction of your attack surface and securing all of it.
### Classification and Risk Scoring
Not every API carries the same risk. A health-check endpoint and a payment processing API are in different universes from a security standpoint. The platform classifies APIs based on what data they handle PII, financial data, credentials, health records and assigns risk scores. This is what keeps security teams from drowning in alerts. You focus on the endpoints that matter most.
### Detection
The API security platform builds behavioral baselines for API usage and flags deviations. BOLA patterns. Schema violations. Unusual request volumes. Credential stuffing. Authentication anomalies. This is the intelligence layer it understands API-specific threats that signature-based rules alone can’t catch. But intelligence without enforcement is just expensive monitoring. That’s where the WAF gateway comes in.
### Enforcement - The Detection-to-Blocking Loop
This is where our solution stands apart. The API security controller detects threats. The WAF gateway enforces inline. It's a closed loop detection that intelligence feeds directly to the gateway, and the gateway blocks in real time. Neither layer is effective alone. The controller without the gateway can only be alert. The gateway without the controller only has signatures and static rules to work with. Together, you get detection depth and enforcement power.
We are the only solution on the market capable of this level of fine-grained blocking. And by fine-grained, we mean something very specific.
Most competing approaches block at the IP level attacker identified; entire IP blocked. In any real environment, API consumers share IPs constantly. Corporate NAT gateways, CDN exit nodes, partner integrations behind shared proxies. Block one IP and you cut off every legitimate consumer behind that address.
Our enforcement goes well beyond endpoint-level blocking. When the controller detects a threat to say, a BOLA attack doesn't just block the endpoint or the source IP. It pushes a targeted rule to the WAF gateway that blocks the specific request pattern and the specific token involved. That means a malicious actor session gets shut down while other users hitting the same endpoint from the same IP continue uninterrupted. The blocking is surgical scoped to the exact behavior and identity, not the network address or even the endpoint as a whole.
This might sound like a subtle technical distinction, but in production it changes everything. It's the difference between a security tool your operations team is confident turning on and one they keep in monitor-only mode because they're afraid of the blast radius.
## The Conversations This Solves
I’m framing these as actual conversations because that’s how they come up in practice.
**“We don’t know how many APIs we have.”** This is the most common starting point, and continuous discovery closes the gap immediately. Every endpoint serving traffic gets catalogued and classified, whether it’s in your documentation or not.
**“Our WAF handles API security.”** Your WAF is the enforcement engine, and that’s exactly the role it should play. What it needs is the right intelligence to feed it. A dedicated API security layer provides continuous discovery, behavioral analysis, and API-specific threat detection and routes that intelligence to your WAF gateway for inline blocking. Think of it as upgrading your WAF’s awareness, not replacing it.
**“We can’t send traffic to a third-party cloud.”** Then don’t. On-prem deployment keeps everything in traffic analysis, detection, enforcement, and reporting inside your perimeter. This is usually a non-negotiable requirement, not a preference for organizations in regulated industries.
**“We need to prove compliance and we’re running out of time.”** Continuous monitoring produces always-current audit evidence. API inventories, risk classifications, threat logs, and remediation records. It replaces the scramble of point-in-time assessments. I’ve watched teams go from dreading audits to walking in with dashboards. It changes the dynamic completely.
**“Dev ships new APIs every week. Security reviews quarterly.”** That gap is where unprotected APIs live. Automated discovery closes it. New endpoints get monitored the moment they start serving traffic.
## Deployment Is Not the Hard Part
I want to spend a minute on this because there’s a perception that on-prem API security deployment is a multi-week project. In my experience, for teams that already have Kubernetes running, it’s measured in hours.
The typical flow:
1. **Create a namespace** in your existing cluster to isolate the security workload.
2. **Set up a Persistent Volume** 128 GB is a common baseline. This uses whatever storage backend your cluster already supports.
3. **Deploy via Helm.** One command. Configuration goes in a values file. Most solutions follow this model because it’s what Kubernetes teams already know.
4. **Configure traffic ingestion on** how the platform gets visibility into API traffic varies by solution, but the goal is the same: continuous observation of every endpoint in your environment.
5. **Integrate with your inline enforcement layer,** typically your WAF or API gateway. This is what closes the detection-to-enforcement loop, so threats get blocked in real time, not just logged.
Upgrades are the same model. Helm upgrade, new chart version, done.
For a detailed step-by-step installation walkthrough, refer to our deployment guide (available to Imperva customers)
The hard part isn’t deployment. It’s usually an organizational conversation about whether to do it in the first place. Once that decision is made, the technical execution is straightforward.
## Where This Is Heading
API-first architecture isn’t slowing down. If anything, the pace is accelerating in exactly the environments that have the strictest infrastructure constraints of financial services, healthcare, government, critical infrastructure. These organizations need API security that respects their boundaries, not one that asks them to relax those boundaries.
Kubernetes gives you the operational foundation. Purpose-built API security gives you visibility, detection, and enforcement. Together, they deliver a security posture that keeps up with how fast your team ships.
And it all runs inside your own perimeter. Which, for a lot of the teams I work with, is the only answer that matters.
Learn more about Thales’s Imperva unified API security platform.
_API security has moved from “nice to have” to “audit requirement.” If your APIs run on-prem, your security needs to run there too. Kubernetes makes that operationally viable. The question isn’t whether to do it. It’s how soon._
## Frequently Asked Questions
### What is on-premises API security?
On-premises API security runs API discovery, threat detection, and enforcement inside your own data center or private cloud instead of sending traffic to a third-party SaaS. It keeps all API traffic, logs, and analysis within your network perimeter—often a hard requirement for banks, healthcare, government, and other regulated organizations with data-sovereignty and compliance constraints.
### Can you run API security on Kubernetes?
Yes. A Kubernetes-native API security platform deploys as lightweight sidecar sensors next to your application pods, feeding mirrored traffic to a controller that builds a live API inventory across REST, GraphQL, gRPC, and SOAP. Because it runs on Kubernetes, it inherits pod-level high availability, Helm-based upgrades, and integration with monitoring stacks like Prometheus and Grafana—so adding it to an existing cluster typically takes hours, not weeks.
### What is a shadow API?
A shadow API is an endpoint serving live traffic that is not in any documentation, Swagger file, or official inventory—often an old version, partner integration, or internal debugging endpoint that was never decommissioned. Continuous, traffic-based API discovery surfaces shadow (and “zombie”) APIs so security teams can protect the full attack surface, not just the endpoints they already know about.
The post On-Premises API Security on Kubernetes: What It Actually Looks Like in Practice appeared first on Blog.
Basic Information
ID
IMPERVABLOG:7EE2F10AC3EAE78AF944E8104F323628
Published
Jun 22, 2026 at 11:39