Change:
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-$basearch enabled=1 gpgcheck=1 <del> repo_gpgcheck=1 </del> gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF sudo yum install -y kubectl

Discussion:
, Red Hat-based distributions: we are facing an issue when installing kubectl on Redhat/centos7 VM, and when applying:
I'm going to take the liberty of reformatting the issue description so that it is more readable.
I'm not sure if you're reporting a fault or if you're asking for advice. If there's a fault, please explain how we can replicate it and how the outcome differs from what you expected. If you want advice, GitHub is not the right place for support requests. You could instead check and ask there if your question has not yet been answered. You can also post your question on the or to the forum. /triage needs-information /language en
I'm reporting an issue, when installing kubectl, using the following: yum install -y kubectl The following failure occurs: if I'm setting and to False and trying to again it is installed successfully. I assume that the following are not valid anymore and needs to be updated:
/sig release
Setting in fixes the issue. ( is still enabled, it's just that must be disabled).
It looks as if the Linux advice for is out of date. Ideally, the Linux Foundation / CNCF / Kubernetes project would publish its own artifacts and not rely on Google here. I'm not sure what the fix would be. My guess is that we do prefer to have all signatures valid and not to recommend that people bypass some of the checks. /sig security is this a duplicate of an existing issue? If so, let's make that link.
/remove-triage needs-information
any update on this issue? Looks like the issue is only with x86_64 rpms
I googled and found some related issues: And here is a from So my suggestion for K8s Docs is: In and ,
At a minimum, we should explain in a comment why this setting is OK. Otherwise folks are bound to ask / file issues / etc. Better would be to migrate away from recommending Google-made packages. It'd be better to be wholly neutral of vendors here (publish our own packages); failing that, we can provide links to packages from Linux distributions: Fedora Ubuntu Debian etc.
As far as I digged: [Fedora] It seems that in the official Fedora packages repo (), the package exists: there is no package; see but there exists a .

I am not sure whether this package contains or not. there is no package; see but we might check these: [Ubuntu] It seems that in the official Ubuntu packages repo, the packages (, , ) does not exist. Instead, provides those packages. [Debian] It seems that in the official Debian packages repo, the packages (, , ) does not exist.
To be clear: the packaging sources are in k/release despite being built on my workstation often (needlessly! there's no real reason this can't be part of the Kubernetes release cloud build, we just block changes to the packaging ...), the packages themselves are defined by the project. The google specific part is the package hosting and signing, which piggybacks on the GCP package host. It would be most excellent to move to community packages, but there are none. There are no other deb/rpm packages for Kubernetes. There are more details about the recommendation in the link quoted above. I think we should be linking there.
Based on , I'm persuaded that we can and should omit mention of from the docs. This will apply the YUM default setting which is not to check the signature on repo metadata. Because that metadata is always accessed over TLS, and the webservers are run by an organization with a reputation for doing TLS well, I think it's absolutely fine.
/triage accepted /priority important-soon
/assign
one word - thank u