Code change:
return rt.Response, rt.Err } <ins> func TestMaskValue(t *testing.T) { tcs := []struct { key      string value    string expected string }{ { key:      "Authorization", value:    "Basic YWxhZGRpbjpvcGVuc2VzYW1l", expected: "Basic <masked>", }, { key:      "Authorization", value:    "basic", expected: "basic", }, { key:      "Authorization", value:    "Basic", expected: "Basic", }, { key:      "Authorization", value:    "Bearer cn389ncoiwuencr", expected: "Bearer <masked>", }, { key:      "Authorization", value:    "Bearer", expected: "Bearer", }, { key:      "Authorization", value:    "bearer", expected: "bearer", }, { key:      "Authorization", value:    "bearer ", expected: "bearer", }, { key:      "Authorization", value:    "Negotiate cn389ncoiwuencr", expected: "Negotiate <masked>", }, { key:      "ABC", value:    "Negotiate cn389ncoiwuencr", expected: "Negotiate cn389ncoiwuencr", }, { key:      "Authorization", value:    "Negotiate", expected: "Negotiate", }, { key:      "Authorization", value:    "Negotiate ", expected: "Negotiate", }, { key:      "Authorization", value:    "negotiate", expected: "negotiate", }, { key:      "Authorization", value:    "abc cn389ncoiwuencr", expected: "<masked>", }, { key:      "Authorization", value:    "", expected: "", }, } for _, tc := range tcs { maskedValue := maskValue(tc.key, tc.value) if tc.expected != maskedValue { t.Errorf("unexpected value %s, given %s.", maskedValue, tc.value) } } } </ins> func TestBearerAuthRoundTripper(t *testing.T) { rt := &testRoundTripper{} req := &http.Request{}

Related discussion:
text: This issue was reported in the Description Kubernetes requires an authentication mechanism to enforce users’ privileges. One method of authentication, bearer tokens, are opaque strings used to associate a user with their having successfully authenticated previously. Any user with possession of this token may masquerade as the original user (the “bearer”) without further authentication. Within Kubernetes, the bearer token is captured within the hyperkube kube-apiserver system logs at high verbosity levels (--v 10). A malicious user with access to the system logs on such a system could masquerade as any user who has previously logged into the system. Exploit Scenario Alice logs into a Kubernetes cluster and is issued a Bearer token. The system logs her token. Eve, who has access to the logs but not the production Kubernetes cluster, replays Alice’s Bearer token, and can masquerade as Alice to the cluster. Recommendation Short term, remove the Bearer token from the log. Do not log any authentication credentials within the system, including tokens, private keys, or passwords that may be used to authenticate to the production Kubernetes cluster, regardless of the logging level. Long term, either implement policies that enforce code review to ensure that sensitive data is not exposed in logs, or implement logging filters that check for sensitive data and remove it prior to outputting the log. In either case, ensure that sensitive data cannot be trivially stored in logs. Anything else we need to know?: See for current status of all issues created from these findings. The vendor gave this issue an ID of TOB-K8S-001 and it was finding 6 of the report. The vendor considers this issue Medium Severity. To view the original finding, begin on page 31 of the Environment: Kubernetes version: 1.13.4
/sig auth /sig api-machinery
/remove-kind feature /kind bug
Should remote the "Authorization" header here?
for authorization headers, everything after the type should be masked (and potentially, only recognized auth types should be logged). Something like:
I think people would be unpleasantly surprised to see credentials in a logfile after turning up logging to debug an issue. /priority important-soon
Does either of you intend to createe PR to remove the "Authorization" header ?