Change:
matchByteArg(nil, actualCfg.TLSClientConfig.CAData, t) } <ins> func TestCAOverridesCAData(t *testing.T) { file, err := ioutil.TempFile("", "my.ca") if err != nil { t.Fatalf("could not create tempfile: %v", err) } defer os.Remove(file.Name()) config := createCAValidTestConfig() clientBuilder := NewNonInteractiveClientConfig(*config, "clean", &ConfigOverrides{ ClusterInfo: clientcmdapi.Cluster{ CertificateAuthority: file.Name(), }, }, nil) actualCfg, err := clientBuilder.ClientConfig() if err != nil { t.Fatalf("Unexpected error: %v", err) } matchBoolArg(false, actualCfg.Insecure, t) matchStringArg(file.Name(), actualCfg.TLSClientConfig.CAFile, t) matchByteArg(nil, actualCfg.TLSClientConfig.CAData, t) } </ins> func TestMergeContext(t *testing.T) { const namespace = "overridden-namespace"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Created cluster with , which generated its own self-signed certificate and put in . Put (API) nodes behind HTTPS ELB and for SSL termination. Run any command that has to hit the API (That's annoying because the CA that signed the cert is a public CA, and the root cert is in my OS keystore. Potentially another bug?) Download the appropriate key from (In my case, AWS ACM certificate = ) Use the certificate to attempt the same request What you expected to happen: Commandline-specified certificate overrides any other options How to reproduce it (as minimally and precisely as possible): Put any in for your host and attempt to override on cmdline. Anything else we need to know?: seems to be where the problem comes from, it's not differentiating "param came from cmdline" from "have param". If I remove the from then it works for both intended cases - either with specifying the CA cert on cmdline or via system certs. Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: AWS OS (e.g. from /etc/os-release): OSX Kernel (e.g. ):Install tools:Others:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Still a problem. /remove-lifecycle stale
Just ran into this as well with 1.9.0
also with 1.9.3 This is very annoying. It says "certificate-authority-data will override" but it will fail and do nothing, exiting with 0. It should at least do the override and try to execute
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale Any chance of someone looking at this? Or at least freezing status, since it's evergreen until actually fixed?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale References from other tickets don't change this timer?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with .

Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/assign
any chance this can be reopened? still seems to be a problem with 1.20 of kubectl