Introduction

If you want to deny access to specific HTTP paths in Kubernetes, you need an L7 HTTP routing solution, not a pure network policy. This is the key architectural point. Kubernetes NetworkPolicy works at the IP and port level, so it cannot say “allow /api but deny /admin.” Path-based denial belongs in the ingress controller, an API gateway, or the application itself.

Why NetworkPolicy Cannot Deny Paths

NetworkPolicy controls traffic using concepts such as:

• pod selectors
• namespace selectors
• ingress and egress peers
• ports and protocols

It does not inspect HTTP request paths.

So this is possible with NetworkPolicy:

• allow traffic from namespace frontend to service port 80

This is not possible with NetworkPolicy:

• allow /public
• deny /private

That distinction matters because many Kubernetes questions mix “network deny” and “URL path deny” as if they were the same thing.

The Usual Solution: Configure the Ingress Controller

If you are using an ingress controller such as NGINX Ingress, Traefik, or a cloud-managed gateway, path-based rules belong there.

One simple approach is to route sensitive paths differently. For example, with NGINX Ingress you can return a 403 for a specific path using a configuration snippet.

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app-ingress
5  annotations:
6    nginx.ingress.kubernetes.io/configuration-snippet: |
7      if ($request_uri ~* "^/private") {
8        return 403;
9      }
10spec:
11  ingressClassName: nginx
12  rules:
13    - host: example.com
14      http:
15        paths:
16          - path: /
17            pathType: Prefix
18            backend:
19              service:
20                name: app-service
21                port:
22                  number: 80

This is controller-specific, which is the important tradeoff. Path denial is possible, but the exact syntax depends on the ingress technology you chose.

A Cleaner Pattern: Route Denied Paths to a Blocking Backend

Sometimes a more maintainable option is to route blocked paths to a tiny service that always returns 403 or 404.

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app-ingress
5spec:
6  ingressClassName: nginx
7  rules:
8    - host: example.com
9      http:
10        paths:
11          - path: /private
12            pathType: Prefix
13            backend:
14              service:
15                name: deny-service
16                port:
17                  number: 80
18          - path: /
19            pathType: Prefix
20            backend:
21              service:
22                name: app-service
23                port:
24                  number: 80

This keeps policy visible in plain routing configuration instead of embedding controller-specific logic snippets.

It is often easier for teams to reason about because the deny behavior is explicit.

Ingress vs Gateway vs Application Logic

There are three common layers where path denial can live:

• ingress controller annotations or custom snippets
• API gateway or service mesh HTTP policy
• application code itself

Choose based on ownership and complexity.

For example:

• if the path rule is infrastructure-wide, ingress or gateway is a good fit
• if the rule depends on user identity or business logic, application code is usually better
• if the cluster already uses a gateway API or service mesh, central policy may be cleaner than ingress annotations

The technical answer is not only “can it be done,” but also “which layer owns the rule.”

Status Code Choice Matters

Denying a path does not always mean returning 403.

Sometimes you may prefer:

• '403 Forbidden when the path exists but access is denied'
• '404 Not Found when you do not want to reveal the endpoint'
• redirect to another path when the route should be hidden behind a login flow

That is a product and security decision, not just a YAML decision.

Use Auth for Real Access Control

Path denial alone is often not enough. If the path should be available to some users but not others, use authentication or authorization instead of hard denial.

For example, an ingress controller may support:

• external auth integration
• basic auth
• JWT validation
• OAuth or OpenID Connect flows through a gateway

Static path blocking is best for paths that should be unavailable to everyone at that entry point.

Common Pitfalls

The biggest pitfall is trying to solve HTTP path restrictions with NetworkPolicy. It cannot see HTTP semantics.

Another issue is depending heavily on controller-specific annotations without documenting them. That can make migrations harder.

Teams also sometimes return 403 when 404 would be the safer information-disclosure choice.

Finally, do not confuse “deny this path for everyone” with “protect this path with authentication.” Those are different requirements.

Summary

• 'NetworkPolicy cannot deny specific HTTP paths because it works below the HTTP layer.'
• Path-based denial belongs in the ingress controller, gateway, or application logic.
• A controller-specific snippet or a dedicated deny backend are common implementation options.
• Choose 403, 404, or redirect behavior deliberately.
• Use authentication or authorization when the path should be selectively available rather than universally blocked.