How to Enforce Client Certificate Validation on Specific Paths with NGINX Ingress Controller in Kubernetes?

Based on the official documentation for the NGINX Ingress Controller, client certificate authentication (configured via the annotation for example,

YAMLCopied
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"

) is applied at the Ingress (and therefore location) level and cannot be directly limited to specific paths within a single Ingress resource.

Options and Workarounds

1. Separate Ingress Resources by Path
   One common workaround is to split your configuration into two Ingress resources—one for the path that requires client certificates and one for the path that does not. However, because both resources use the same hostname, achieving this separation isn’t straightforward. In practice, Ingress rules for the same host are merged, and the global TLS settings may be applied to all locations. This merging behavior means that simply splitting the paths into separate resources typically does not work as desired.

2. Custom Configuration Snippets
   Some users have experimented with custom snippets (using annotations like nginx.ingress.kubernetes.io/configuration-snippet) to inject location-specific settings. For instance, you might try to override the client certificate validation configuration for the /tool path. That said, this approach is considered advanced and is not officially supported as a path-specific override for TLS client authentication. It may look something like:

   YAMLCopied
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: app-ingress
     annotations:
       nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"  # global setting
       nginx.ingress.kubernetes.io/configuration-snippet: |
         location /tool/ {
           auth_request off;
           # You may need additional configuration here to ensure the client cert auth
           # directives are not inherited. Adjust with caution.
         }
   spec:
     rules:
     - host: app.example.com
       http:
         paths:
         - path: /auth
           pathType: Prefix
           backend:
             service:
               name: auth-service
               port:
                 number: 80
         - path: /tool
           pathType: Prefix
           backend:
             service:
               name: tool-service
               port:
                 number: 80

   Caveats:

   • Overriding built-in SSL/TLS authentication directives via configuration snippets can lead to unexpected behavior.
   • The exact snippet syntax may vary depending on your NGINX Ingress Controller version and the rest of your configuration.
   • This is not officially documented as a supported way to control client certificate validation on a per-path basis.

3. Switching Ingress Controllers
   If per-path client certificate validation is a strict requirement, you might consider other Ingress controllers or service meshes that support more granular, location-specific authentication policies. Some alternatives (e.g., Istio with its more advanced routing and policy features) provide a finer level of control over security policies per route. Evaluating options like Istio, Kong, or Traefik might be worthwhile if you need that level of granularity.

Summary

Currently, with the NGINX Ingress Controller, client certificate authentication is configured as a global setting for an Ingress resource, and there isn’t an officially supported way to enable or disable it on a per-path basis within the same Ingress.

If you must stick with NGINX, consider using configuration snippets as an experimental workaround or redesign your architecture to use a more capable ingress solution that supports per-path policies.

Always test these approaches in a non-production environment, as tweaking low-level NGINX configuration may yield side effects.