Summary

Add an insecure field to the Kubernetes provider's KubernetesServer configuration that allows skipping TLS certificate verification when connecting to Kubernetes API servers.

Use 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.net domains). These certificates are trusted by system CA roots, but external-secrets currently requires an explicit caBundle or caProvider configuration.

This creates operational friction because:

1. Users must manually fetch and maintain CA certificates
2. When using proxies with well-known CAs (Let's Encrypt), the system already trusts these certificates
3. Other Kubernetes tools (like kubectl, Headlamp) work seamlessly because Go's client-go uses system CA roots by default

Current Behavior

apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
spec:
  provider:
    kubernetes:
      server:
        url: "https://my-cluster-proxy.example.com"
        # ❌ Fails validation: "a CABundle or CAProvider is required"
      auth:
        serviceAccount:
          name: "my-sa"

Proposed Behavior

apiVersion: external-secrets.io/v1
kind: ClusterSecretStore
spec:
  provider:
    kubernetes:
      server:
        url: "https://my-cluster-proxy.example.com"
        insecure: true  # ✅ Skips TLS verification
      auth:
        serviceAccount:
          name: "my-sa"

Implementation

I have a working implementation ready that:

• Adds Insecure bool field to KubernetesServer in both v1 and v1beta1 APIs
• Updates the provider's auth logic to use the insecure flag
• Updates validation to allow insecure mode without CA requirements
• Includes test coverage
• Includes documentation with usage examples and security warnings

Security Considerations

The documentation and code comments clearly warn that:

• This disables TLS certificate verification
• This is NOT recommended for production use
• Users should prefer providing proper CA certificates when possible

This follows the same pattern as other tools that offer --insecure-skip-tls-verify options.

Alternatives Considered

1. Use system CA roots by default when no CA is specified - More secure, but larger change to existing behavior
2. Sidecar injection for CA management - More complex operationally
3. Explicit ISRG Root X1 CA bundle - Works but requires manual maintenance

The insecure option provides an explicit opt-in mechanism that maintains backwards compatibility while addressing the use case.