Change:
<ins> // +build darwin linux /* Copyright 2021 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package copycerts import "golang.org/x/sys/unix" // on unix where umask may be in effect, clear umask so tests // are not sensitive to the developer's system umask func setNoUmask() { unix.Umask(0) } </ins>

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Running locally. Today? There is none, but I'm not filing this as a flaking test because it's a dependable failure, not a flake. I suspect this depends on the user's umask given the error: originally /area kubeadm /sig cluster-lifecycle
/assign
there were related changes to TestDownloadCerts last month: we could pin the mode for these newly created files in kubeadm. /triage accepted
but the problem seems odd. kubeadm uses client-go utils for writing a cert file with mode 644: i don't understand why something would override this mode to 0640.
i don't understand why something would override this mode to 0640. From the initial issue filing: -- users may be running in an environment with a less permissive umask, but the test depends on a full permissive umask.
ok, right. a quick fix would be to get the current process umask and expect it to be applied to the file permissions: but note: the test should be made Unix only too.
I think it would be reasonable to just set umask without getting it in the TestMain for the package. IIRC go runs tests as a binary / process per package, so it would only affect that package. We could make setting the umask only happen on unix without making the tests unix only as well, by using a conditionally compiled wrapper. I can send a PR for this, I suspect the system umask is google's workstation customization (~~debian testing), and probably relatively unusual elsewhere. I recall now we've run into this in the past during builds where e.g. does not result in the permissions on other systems so we've chmod to e.g.
the test would fail on Windows because -would always return there. so we should os-branch the checks.
I'm not sure I understand the windows part tbh, I think this particular failure can be addressed without affecting windows though. After meetings I got around to confirming on my personal debian stable instance reports while on my "gLinux" (~debian testing) workstation it reports . AFAICT should be more or less the standard across distros but debian and ubuntu at least provide a mechanism out of the box to configure it for the system.

yeah, the test is already broken on non-Unix, so we could just set the umask (syscall.Umask) to make the test happy. the non-Unix fix seems like something that can be done separately.
filed to set it to 0 in test main so it would be technically not umask sensitive anymore on linux and macOS at least.