|
| 1 | +# GEP-4152: Extending TLS Validation in BackendTLSPolicy |
| 2 | + |
| 3 | +* Issue: [#4152](https://github.com/kubernetes-sigs/gateway-api/issues/4152) |
| 4 | +* Status: Provisional |
| 5 | + |
| 6 | +## TLDR |
| 7 | + |
| 8 | +The ability for the `BackendTLSPolicy` to skip TLS verification or to validate |
| 9 | +certificates based on their fingerprint or public key hash. |
| 10 | + |
| 11 | +## Motivation |
| 12 | + |
| 13 | +The current `BackendTLSPolicy` follows a secure-by-default approach that requires |
| 14 | +users to provide a trusted CA certificate bundle or rely on the system’s default |
| 15 | +certificate store (which typically includes root CAs) to validate backend server |
| 16 | +certificates. However, real-world deployments include cases where strict |
| 17 | +certificate validation may not be possible or practical, e.g., Development and |
| 18 | +testing environments that use self-signed certificates generated dynamically at |
| 19 | +runtime. |
| 20 | + |
| 21 | +In such scenarios, users may need the flexibility to disable certificate |
| 22 | +verification or to use certificate pinning. Certificate pinning offers a safer |
| 23 | +and more controlled alternative, instead of bypassing TLS validation, the gateway |
| 24 | +verifies that the backend’s certificate matches a known fingerprint or public key |
| 25 | +hash. This preserves the confidentiality and integrity guarantees of TLS while |
| 26 | +removing the operational overhead of managing full certificate chains or trusted |
| 27 | +CA bundles. |
| 28 | + |
| 29 | +### User Stories |
| 30 | + |
| 31 | +* As an application developer, I want the option to disable backend TLS |
| 32 | + certificate verification on a per-backend basis, so I can connect to services |
| 33 | + using dynamically generated or self-signed certificates during development or |
| 34 | + testing. |
| 35 | +* As an application developer, I want secure-by-default behavior, ensuring that |
| 36 | + certificate verification is always enabled unless I explicitly opt out, to |
| 37 | + prevent accidentally deploying insecure configurations to production. |
| 38 | +* As an application developer, I want an alternative to disabling verification, |
| 39 | + such as certificate or SPKI pinning, so I can securely communicate with |
| 40 | + backends using self-signed certificates without managing CA bundles. |
| 41 | +* As a gateway operator, I want to control whether skipping TLS validation is |
| 42 | + permitted for specific Gateways. |
| 43 | +* As a security officer, I want transparency and auditability into where TLS |
| 44 | + verification has been disabled. |
| 45 | + |
| 46 | +## Goals |
| 47 | + |
| 48 | +* Enable connecting to backends over TLS without requiring certificate |
| 49 | + verification. |
| 50 | +* Support certificate and SPKI pinning as alternatives to disabling verification |
| 51 | + or relying on CA trust chains. |
| 52 | +* Maintain a secure-by-default approach, with certificate verification enabled |
| 53 | + unless explicitly opted out. |
| 54 | +* Provide operator-level controls so Gateway constraints can restrict or permit |
| 55 | + the use of skip-verify. |
| 56 | +* Provide clear runtime indicators that security is degraded when TLS validation |
| 57 | + is disabled. |
| 58 | + |
| 59 | +## API |
| 60 | + |
| 61 | +**TODO**: First PR will not include any implementation details, in favor of |
| 62 | +building consensus on the motivation, goals and non-goals first. _"How?"_ we |
| 63 | +implement shall be left open-ended until _"What?"_ and _"Why?"_ are solid. |
| 64 | + |
| 65 | +## References |
| 66 | + |
| 67 | +* [GEP-1897: BackendTLSPolicy - Explicit Backend TLS Connection Configuration](https://gateway-api.sigs.k8s.io/geps/gep-1897/) |
0 commit comments