fix: support OIDC refresh and trusted CA server certificates

[nklmilojevic]

OIDC kubeconfigs could fail at TLS verification when the API server used a trusted CA as its server certificate. Expired OIDC tokens also could not refresh because the build did not enable the kube oidc feature.

Enable OIDC token refresh and allow auth-provider entries with name: oidc to use the existing CA server certificate exception. The certificate must still exactly match a trusted kubeconfig CA and pass the existing checks. Exec plugins and other providers retain standard verification. Update the documentation with the OIDC configuration requirements and separate identity provider trust requirements.

Validation:

• just check passed: formatting, Clippy, and 1,682 tests passed; 2 ignored.
• A mock HTTPS issuer verifies discovery, client credentials, and the refresh-token request. A keyboard test then verifies that the Kubernetes watch uses the returned ID token. This covers both client construction paths.
• The mock issuer uses a fixture CA in a child process, so other tests retain their own trust settings.
• Keyboard tests also cover a valid cached OIDC token with a CA server certificate and an expired token that enters the refresh error path.
• The expired-token regression test failed with OIDC disabled and passed after the feature was enabled.
• Guard tests cover other providers, exec plugins, insecure mode, and CA file reloads.
• A live identity provider was not used.

Closes #597

[greptile-apps]

Greptile Summary

This PR enables kube-client’s OIDC support and permits OIDC-authenticated kubeconfigs to use the existing, narrowly bounded CA server-certificate exception.

• Enables the kube oidc feature required for expired-token refresh.
• Keeps exec plugins, non-OIDC auth providers, insecure TLS, and CA-file configurations on standard certificate verification.
• Documents OIDC refresh requirements and the identity provider’s separate system-trust boundary.
• Adds an end-to-end mock issuer test proving refresh and refreshed-token use through both client-construction paths, addressing the previous review finding.

Confidence Score: 5/5

The PR appears safe to merge; the previously missing OIDC refresh success path is now covered through both supported client-construction paths.

The mock issuer verifies discovery and refresh request details, while the Kubernetes API harness confirms that the returned ID token—not the expired cached token—is applied to subsequent requests. The TLS exception remains limited to qualifying configured CA certificates and OIDC providers, with existing exclusions preserved.

Important Files Changed

Filename	Overview
Cargo.toml	Enables kube-client’s OIDC feature so expired OIDC credentials can be refreshed.
src/server_tls.rs	Allows only OIDC auth-provider configurations through the existing CA server-certificate exception while preserving all other guards.
src/app/tests.rs	Refactors the TLS request harness to support authentication providers and verify bearer tokens across both client paths.
src/app/tests/oidc.rs	Adds an isolated mock HTTPS issuer test covering discovery, refresh exchange, and use of the refreshed ID token.
docs/debugging.md	Documents OIDC refresh fields and distinguishes Kubernetes API certificate handling from identity-provider system trust.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Kube configuration] --> B{OIDC auth provider?}
  B -- No --> C[Standard kube TLS verification]
  B -- Yes --> D{Configured certificate qualifies<br/>for CA server exception?}
  D -- No --> C
  D -- Yes --> E[Custom Kubernetes API TLS verifier]
  B -- Yes --> F{ID token valid?}
  F -- Yes --> G[Send cached ID token]
  F -- No --> H[Discover identity provider]
  H --> I[Refresh through separate HTTPS connection<br/>using system trust]
  I --> J[Send refreshed ID token]
  E --> K[Kubernetes API request]
  G --> K
  J --> K

Loading

_{Reviews (2): Last reviewed commit: "test: verify successful OIDC token refre..." | Re-trigger Greptile}