What problem are you trying to solve?

It's possible to log Kubeconfig, and Config with Debug - which looks like it will just log all secret information by default.
I want to make this slightly harder to do. Similarly in request parameters that may have access to them.

Describe the solution you'd like

A practice I've seen around is to use:

• secrecy crate to wrap the sensitive credentials
• tower_http::sensitive_headers to mark access creds as sensitive

The first can be used in in the Config, Kubeconfig to help avoiding secrets these being logged (unless explicitly requested via Secret::expose_secret).

The second may be helpful, if it fits into the layer stack, not sure about it.

Describe alternatives you've considered

Removing Debug

Documentation, Adoption, Migration Strategy

Might be considered a breaking change to the Kubeconfig or Config, but can be documented, and it is very light.

Target crate for feature

kube-client

• Request headers (fortification: preventing secret leaks #751 (comment))
• AuthInfo password (Use SecretString in AuthInfo to avoid credential leaking #766)
• AuthInfo token (Use SecretString in AuthInfo to avoid credential leaking #766)
• AuthInfo client_key_data
  • Copied to Config identity_pem as well. Cleaned up in Remove crate private identity_pem field from Config #771.