feat(kubernetes): add insecure TLS option for API server connections#5905
feat(kubernetes): add insecure TLS option for API server connections#5905rajsinghtech wants to merge 1 commit intoexternal-secrets:mainfrom
Conversation
WalkthroughAdds an Changes
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Add an `insecure` field to KubernetesServer that allows skipping TLS certificate verification when connecting to Kubernetes API servers. This is useful when: - Accessing clusters through proxies that use their own TLS certificates (e.g., Tailscale API server proxy with Let's Encrypt certs) - The API server uses certificates from a CA not in the system trust store - Testing or development environments with self-signed certificates When `insecure: true` is set, the CABundle and CAProvider fields are no longer required. Includes: - API type changes for v1 and v1beta1 - Provider implementation to honor the insecure flag - Validation logic to allow insecure mode without CA - Test coverage for insecure mode validation - Documentation with usage examples and security warnings Signed-off-by: Raj Singh <raj@tailscale.com>
ba0bb53 to
2f34805
Compare
|
|
This is a no-go for me. We should not allow users to set up insecure configuration in the upstream project. We didn't do it so for any providers up to this far, including vault. Either you set TLS (and verify), or you don't. |
|
IMO this should be handled on the user side by creating a custom |
|
We talked about this and it will be switched to loading the root certificate instead. |



Summary
Add an
insecurefield to the Kubernetes provider'sKubernetesServerconfiguration that allows skipping TLS certificate verification when connecting to Kubernetes API servers.Closes #5904
Changes
Insecure boolfield toKubernetesServerstructauth.goto usec.store.Server.Insecureinstead of hardcodedfalsevalidate.goto allowinsecure: truewithout requiring CAUse Case
When accessing Kubernetes clusters through API proxies like Tailscale's Kubernetes API server proxy, the proxy terminates TLS and presents its own certificate (typically Let's Encrypt for
*.ts.netdomains). These certificates are trusted by system CA roots, but external-secrets currently requires an explicitcaBundleorcaProvider.This creates friction because other K8s tools (kubectl, Headlamp, etc.) work seamlessly since Go's
client-gouses system CA roots by default.Usage
Security Notice
The documentation clearly warns that:
This follows the pattern of
--insecure-skip-tls-verifyin kubectl and other tools.Testing
All existing tests continue to pass.
Adds support for skipping TLS certificate verification when connecting to Kubernetes API servers via a new Insecure field on the KubernetesServer struct.
Changes
Insecure booltoKubernetesServerin both apis/externalsecrets/v1 and v1beta1.Server.Insecureis false;TLSClientConfig.Insecurenow reflects the server'sInsecuresetting instead of being hard-coded false.Insecure: truewithout requiringcaBundleorcaProvider; updated error message to reference the new option.insecure mode without ca is valid; existing tests continue to pass.Use case: Reduces friction for connections via API proxies or setups where system CA roots already trust the proxy cert (aligns behavior with kubectl).
Security note: Disabling TLS verification is unsafe for production; prefer supplying proper CA certificates where possible.
Closes #5904.