Install kubectl only from kubernetes.io instructions: the binary from dl.k8s.io on any OS, the signed pkgs.k8s.io repository on Debian, Ubuntu, RHEL or SUSE, or Homebrew, winget, Chocolatey or Scoop as the Kubernetes docs list them. Install minikube from minikube.sigs.k8s.io and its GitHub releases. Check each SHA-256 file, verify kubectl's cosign signature, and keep kubectl within one minor version of your cluster.
Most Kubernetes tutorials start with installing both tools, and most install answers stop once kubectl get pods prints something. This guide goes further. Every command below comes from the Kubernetes documentation, the pkgs.k8s.io announcement, the minikube documentation or the Sigstore documentation, all fetched on 23 October 2026, and each step says what it trusts.
Key takeaways
- kubectl is the Kubernetes command line client. minikube runs a small Kubernetes cluster on your own computer.
- Keep kubectl within one minor version of the cluster. A v1.37 client is supported against v1.36, v1.37 and v1.38 control planes.
- Linux packages live at pkgs.k8s.io, one repository per minor version. The old
apt.kubernetes.ioandyum.kubernetes.iowent away on 4 March 2024. - Every kubectl binary on dl.k8s.io has a .sha256 file and a cosign keyless signature. The checksum proves integrity; the signature proves the Kubernetes release process built it.
- minikube publishes a .sha256 beside each raw binary on its GitHub release page, but no cosign signatures.
- Pick a minikube driver on purpose: Docker or KVM2 on Linux, Docker or VFkit on macOS, Hyper-V or Docker on Windows.
- A kubeconfig is a credential, and the Kubernetes docs warn a crafted one can lead to code execution. Never commit one.
- Krew plugins are, in the Kubernetes docs' words, "not audited for security."
What kubectl and minikube do
The Kubernetes "Install Tools" page describes kubectl as the tool for running commands against Kubernetes clusters: deploying applications, inspecting and managing resources, and viewing logs. It is a single binary with no daemon. Its configuration lives in ~/.kube/config by default.
minikube runs an all in one or multi node local cluster on Windows, macOS or Linux, for learning and daily development. It builds the cluster inside a container or virtual machine, which is why it needs a driver. When minikube start succeeds it adds a minikube context to your kubeconfig. If you have no kubectl, minikube can download one and run it as minikube kubectl --, which is convenient but leaves you with two kubectl binaries to keep patched.
The version skew rule
The Kubernetes version skew policy says kubectl "is supported within one minor version (older or newer) of kube-apiserver." Outside that window, some commands fail in confusing ways. The project maintains release branches for the three most recent minor releases (1.37, 1.36 and 1.35 at the time of writing), and Kubernetes 1.19 and newer get roughly a year of patch support. minikube supports the latest three minor Kubernetes releases through --kubernetes-version.
On 23 October 2026, https://dl.k8s.io/release/stable.txt returned v1.37.1. The official pages use v1.37.0 in pinned examples, so substitute the version you want.
Which install route should you use?
| Your machine | kubectl route | What gets verified | Minor upgrades | minikube route |
|---|---|---|---|---|
| Ubuntu or Debian | pkgs.k8s.io apt repository | apt checks every package against the repo key | Edit the version in the repo file | Binary or .deb |
| RHEL, CentOS, Fedora | pkgs.k8s.io yum repository | dnf checks signatures with gpgcheck=1 | Edit the version in the repo file | Binary or .rpm |
| openSUSE or SLES | pkgs.k8s.io zypper repository | zypper shows the key fingerprint to accept | Edit the version in the repo file | Binary or .rpm |
| Any Linux, no root, CI, other distros | Binary from dl.k8s.io | SHA-256 plus cosign | Download the new binary | Binary |
| macOS, Apple silicon or Intel | Homebrew or the darwin binary | Binary: SHA-256 and cosign | brew upgrade or new binary | Homebrew or binary |
| Windows 10 or 11 | winget, Chocolatey, Scoop or kubectl.exe | Binary: SHA-256 via Get-FileHash | Package manager or new exe | winget, Chocolatey or .exe |
| WSL 2 | The Linux route inside the distribution | Same as Linux | Same as Linux | Linux route, Docker driver |
The binary route gives the strongest proof about the exact file you run. The repository route gives the easiest patching. Pick one per machine so you never wonder which kubectl is first on your PATH.
How to install kubectl on Linux, step by step
The Kubernetes Linux page documents the binary with curl, native package management through pkgs.k8s.io, and snap or Homebrew.
Option 1: the kubectl binary with curl
Download the latest release for x86-64 (swap amd64 for arm64 on ARM):
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
To pin a version instead, the docs replace the stable.txt lookup with the version:
curl -LO https://dl.k8s.io/release/v1.37.0/bin/linux/amd64/kubectl
Pin on shared machines and in CI. stable.txt changes the moment a release ships, so two people running the same command a day apart can get different binaries.
Download the checksum for the same version and architecture, and check:
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
echo "$(cat kubectl.sha256) kubectl" | sha256sum --check
A good file prints kubectl: OK; a bad one prints kubectl: FAILED and exits nonzero. The docs stress downloading the same version of binary and checksum.
Install it owned by root, so nothing running as your user can swap it:
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
Without root, the docs show a per user install:
chmod +x kubectl
mkdir -p ~/.local/bin
mv ./kubectl ~/.local/bin/kubectl
# and then append (or prepend) ~/.local/bin to $PATH
Confirm:
kubectl version --client
Option 2: the pkgs.k8s.io apt repository on Debian and Ubuntu
Install prerequisites:
sudo apt-get update
# apt-transport-https may be a dummy package; if so, you can skip that package
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
Download the signing key. The docs say the same key is used for all repositories, so the version in the URL does not matter:
# If the folder `/etc/apt/keyrings` does not exist, it should be created before the curl command, read the note below.
# sudo mkdir -p -m 755 /etc/apt/keyrings
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.37/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg # allow unprivileged APT programs to read this keyring
On releases older than Debian 12 and Ubuntu 22.04, uncomment the mkdir line first. Then add the repository for your minor version and install:
# This overwrites any existing configuration in /etc/apt/sources.list.d/kubernetes.list
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.37/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list # helps tools such as command-not-found to work correctly
sudo apt-get update
sudo apt-get install -y kubectl
signed-by is the important part. It scopes the Kubernetes key to this one repository instead of letting it vouch for packages from any source.
Option 3: the yum repository on RHEL, CentOS and Fedora
# This overwrites any existing configuration in /etc/yum.repos.d/kubernetes.repo
cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.37/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.37/rpm/repodata/repomd.xml.key
EOF
sudo dnf install -y kubectl
gpgcheck=1 makes dnf refuse unsigned packages. Never set it to 0 to get past an error. The docs do not name Amazon Linux or other dnf distributions, so on those the binary method avoids guessing.
Option 4: openSUSE and SLES with zypper
# This overwrites any existing configuration in /etc/zypp/repos.d/kubernetes.repo
cat <<EOF | sudo tee /etc/zypp/repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.37/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.37/rpm/repodata/repomd.xml.key
EOF
sudo zypper update
sudo zypper install -y kubectl
zypper asks whether to trust the new key. The sample prompt in the docs uses a placeholder fingerprint, so compare against the fingerprint in the verification section below instead.
Option 5: snap or Homebrew on Linux
snap install kubectl --classic
brew install kubectl
These builds are packaged by those ecosystems, so you trust their build and update process as well as the Kubernetes release.
Why apt.kubernetes.io no longer works
On 15 August 2023 the Kubernetes project announced pkgs.k8s.io, community owned repositories built on the openSUSE Build Service, to replace the Google hosted apt.kubernetes.io and yum.kubernetes.io. The legacy repositories were deprecated on 31 August 2023, frozen on 13 September 2023 and "went away on March 4, 2024." Three differences catch people following old tutorials: there is one repository per minor version, packages start at v1.24.0, and package revisions now look like 1.28.0-1.1 instead of 1.28.0-00. If a guide tells you to add apt.kubernetes.io, it is out of date. Do not look for a copy of it elsewhere.
kubectl on WSL
A WSL 2 distribution is Linux, so follow the Linux steps inside it. If Docker Desktop is installed on the Windows side, check which kubectl your shell picks up with kubectl version --client. Our Docker install guide covers Docker Desktop with the WSL 2 backend.
How to install kubectl on macOS
The macOS page lists the binary, Homebrew and MacPorts. For the binary on Apple silicon (use darwin/amd64 on Intel):
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl"
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl.sha256"
echo "$(cat kubectl.sha256) kubectl" | shasum -a 256 --check
macOS ships shasum rather than sha256sum. Then install it owned by root:
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl
sudo chown root: /usr/local/bin/kubectl
kubectl version --client
rm kubectl.sha256
With Homebrew (either name works):
brew install kubectl
brew install kubernetes-cli
If you have not installed Homebrew yet, see how to install Homebrew on Mac and Linux safely. With MacPorts:
sudo port selfupdate
sudo port install kubectl
How to install kubectl on Windows
The Windows page documents a direct download or curl, plus three package managers.
kubectl.exe with curl
Windows 10 and 11 include curl.exe. Replace the pinned version with the current patch release:
curl.exe -LO "https://dl.k8s.io/release/v1.37.0/bin/windows/amd64/kubectl.exe"
curl.exe -LO "https://dl.k8s.io/v1.37.0/bin/windows/amd64/kubectl.exe.sha256"
Compare by eye in Command Prompt:
CertUtil -hashfile kubectl.exe SHA256
type kubectl.exe.sha256
Or get True or False in PowerShell:
$(Get-FileHash -Algorithm SHA256 .\kubectl.exe).Hash -eq $(Get-Content .\kubectl.exe.sha256)
Then add kubectl's folder to PATH and run kubectl version --client. On a shared machine, use a folder standard users cannot write to; a kubectl.exe in a writable Downloads folder on PATH is easy to replace.
The Kubernetes docs warn that Docker Desktop for Windows adds its own kubectl to PATH. Put your folder earlier in PATH or remove Docker Desktop's copy, or you may patch kubectl and still run the old one.
winget, Chocolatey or Scoop
winget install -e --id Kubernetes.kubectl
choco install kubernetes-cli
scoop install kubectl
The -e flag asks winget for an exact match on the ID, which avoids a similarly named package. Chocolatey and Scoop packages are community maintained, so the trust chain runs through those maintainers too.
How to verify kubectl: checksums and cosign signatures
A checksum answers "did the file arrive as published?" A signature answers "who published it?" Our deep dive on verifying the kubectl binary signature with cosign goes further; here is the working version.
What the .sha256 file proves
Matching the .sha256 beside the binary on dl.k8s.io proves nothing changed between that server and your disk. It does not protect you from a lookalike site, which can publish a fake binary with a matching fake checksum. That is what the signature check is for.
Verifying kubectl's cosign signature
The Kubernetes page "Verify Signed Kubernetes Artifacts" says the release process signs all binary artifacts, including tarballs, SPDX files and standalone binaries, with cosign's keyless signing. You need cosign, curl and jq. Sigstore's installation page lists Homebrew among other routes:
brew install cosign
Fetch kubectl with its signature and certificate, setting URL to your version and platform:
URL=https://dl.k8s.io/release/v1.37.0/bin/linux/amd64
BINARY=kubectl
FILES=(
"$BINARY"
"$BINARY.sig"
"$BINARY.cert"
)
for FILE in "${FILES[@]}"; do
curl -sSfL --retry 3 --retry-delay 3 "$URL/$FILE" -o "$FILE"
done
Then verify:
cosign verify-blob "$BINARY" \
--signature "$BINARY".sig \
--certificate "$BINARY".cert \
--certificate-identity krel-staging@k8s-releng-prod.iam.gserviceaccount.com \
--certificate-oidc-issuer https://accounts.google.com
The identity and issuer flags make this meaningful. Anyone can get a keyless certificate for their own identity; pinning both says "only accept a signature from the Kubernetes release pipeline." The docs note cosign 2.0 and later require both flags, and older versions needed COSIGN_EXPERIMENTAL=1, so old snippets will not run on current cosign. The page lists this feature as beta since Kubernetes v1.26. On 23 October 2026 we confirmed .sig and .cert files exist for the v1.37.1 Linux kubectl.
The same page shows how to verify the Kubernetes release SBOM (SHA-512, SHA-256 and a cosign signature) and the signed control plane images on registry.k8s.io. Platform teams that mirror Kubernetes images internally should verify before mirroring. For air gapped checks, see whether you can verify Sigstore signatures offline.
Checking the pkgs.k8s.io repository key
On the repository routes, the package manager verifies each package against the repository key, so the key itself is what you must get right. GnuPG's --show-keys option prints a key file's details without importing it:
gpg --show-keys /etc/apt/keyrings/kubernetes-apt-keyring.gpg
On 23 October 2026, Release.key for v1.36 and v1.37 were byte for byte identical, matching the docs. It was an RSA 2048 key named isv:kubernetes OBS Project, fingerprint DE15 B144 86CD 377B 9E87 6E1A 2346 54DA 9A29 6436, created 25 August 2022 and showing an expiry of 29 December 2026. The install pages do not publish this fingerprint, so treat our reading as a cross check. If apt later reports an expired key, download Release.key again from pkgs.k8s.io rather than disabling signature checks.
Verification at a glance
| Artifact | Integrity check | Origin check |
|---|---|---|
| kubectl binary, any OS | .sha256 on dl.k8s.io | cosign .sig and .cert, identity pinned |
| kubectl from pkgs.k8s.io | Package manager checks every package | Repo key from pkgs.k8s.io, scoped with signed-by or gpgcheck=1 |
| Kubernetes release SBOM | SHA-512 and SHA-256 files | cosign signature |
| minikube raw binaries | .sha256 on the GitHub release | None published |
| minikube .deb, .rpm, Windows installer | No .sha256 on the release page we checked | HTTPS and the official domain only |
How to install minikube on Linux, macOS and Windows
The minikube start page asks for 2 CPUs or more, 2GB of free memory, 20GB of free disk, an internet connection, and a container or VM manager such as Docker, QEMU, Hyper-V, KVM, Parallels, Podman, VirtualBox or VMware.
minikube on Linux
The binary for x86-64 (swap amd64 for arm64 on ARM):
curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube && rm minikube-linux-amd64
The Debian package or RPM:
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
sudo dpkg -i minikube_latest_amd64.deb
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-latest.x86_64.rpm
sudo rpm -Uvh minikube-latest.x86_64.rpm
The start page also covers ppc64, S390x and beta builds; use stable unless you are testing minikube. The .deb and .rpm install directly with dpkg and rpm, with no signed repository behind them, which is a reason to prefer the raw binary you can check against its .sha256.
minikube on macOS
brew install minikube
If which minikube then fails, the docs suggest relinking:
brew unlink minikube
brew link minikube
Or the binary on Apple silicon (use darwin-amd64 on Intel):
curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube-darwin-arm64
sudo install minikube-darwin-arm64 /usr/local/bin/minikube
minikube on Windows
winget install Kubernetes.minikube
choco install minikube
Or download the .exe in PowerShell, then add it to the machine PATH from an administrator PowerShell:
New-Item -Path 'c:\' -Name 'minikube' -ItemType Directory -Force
$ProgressPreference = 'SilentlyContinue'; Invoke-WebRequest -OutFile 'c:\minikube\minikube.exe' -Uri 'https://github.com/kubernetes/minikube/releases/latest/download/minikube-windows-amd64.exe' -UseBasicParsing
$oldPath = [Environment]::GetEnvironmentVariable('Path', [EnvironmentVariableTarget]::Machine)
if ($oldPath.Split(';') -inotcontains 'C:\minikube'){
[Environment]::SetEnvironmentVariable('Path', $('{0};C:\minikube' -f $oldPath), [EnvironmentVariableTarget]::Machine)
}
Reopen the terminal before running minikube. The start page lists only x86-64 Windows builds.
Verifying the minikube download
The start page has no verification step, but the GitHub release page publishes what you need. For v1.39.0, the latest release on 23 October 2026, it lists .sha256 files for each raw Linux, macOS and Windows binary and the ISO images, plus an SPDX SBOM, minikube_v1.39.0_sbom.spdx. Each .sha256 holds just the hash, the same format as kubectl's, so the check the Kubernetes docs use for kubectl works on minikube too. Run it before the sudo install line, because the documented install command deletes the download:
curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube-linux-amd64.sha256
echo "$(cat minikube-linux-amd64.sha256) minikube-linux-amd64" | sha256sum --check
Use shasum -a 256 --check on macOS, and the Get-FileHash comparison against minikube-windows-amd64.exe.sha256 on Windows. We found no .sha256 for the .deb, .rpm or minikube-installer.exe, and no cosign signatures for minikube binaries.
Choosing a minikube driver
The minikube drivers page lists what each OS supports.
| OS | Preferred | Also supported | Experimental | Notes |
|---|---|---|---|---|
| Linux | Docker, KVM2 | VirtualBox, QEMU, None, SSH | Podman | Docker driver user can reach the Docker daemon, which is root equivalent |
| macOS | Docker, VFkit | VirtualBox, Parallels, VMware Fusion, QEMU, SSH | Podman, Krunkit | VFkit needs macOS 14 and minikube 1.36.0 or later |
| Windows | Hyper-V, Docker | VirtualBox, VMware Workstation, SSH | QEMU, Podman | Enabling Hyper-V needs an administrator and often a reboot |
If an older guide says to use HyperKit on a Mac, the drivers page records a July 2026 change removing HyperKit from the docs. Use VFkit or Docker.
Docker driver
minikube start --driver=docker
minikube config set driver docker
minikube asks for Docker 18.09 or higher (20.10 recommended) set up for a non root user. That means docker group membership, which gives root level control of the host; our Docker install guide explains the trade off. minikube also documents rootless Docker, which needs Docker 20.10 or higher, cgroup v2 delegation and kernel 5.11 or later:
dockerd-rootless-setuptool.sh install -f
docker context use rootless
minikube start --driver=docker --container-runtime=containerd
Hyper-V, KVM2 and VFkit
Hyper-V needs 64 bit Windows 10 Enterprise, Pro or Education. From an administrator PowerShell, then reboot if needed:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
minikube start --driver=hyperv
KVM2 needs libvirt v1.3.1 or higher and qemu-kvm v2.0 or higher from your distribution:
virt-host-validate
minikube start --driver=kvm2
On macOS:
minikube start --driver vfkit
The VM drivers put a full virtual machine boundary between the cluster and your host, a stronger separation than the Docker driver's container.
Start the cluster and connect kubectl
The start page says to run this "from a terminal with administrator access (but not logged in as root)":
minikube start
kubectl get po -A
Or, without a separate kubectl:
minikube kubectl -- get po -A
Leave minikube listening only on your machine. Its FAQ says the project strongly discourages using minikube in production or for remote traffic, and that --listen-address=0.0.0.0 opens your network to the outside world.
Avoiding lookalike downloads and unofficial kubectl plugins
Searches for "download kubectl" return sites that are not the Kubernetes project, some repackaging the binary in their own installer. The official instructions only send you to:
- kubernetes.io for docs and dl.k8s.io for binaries and checksums.
- pkgs.k8s.io for Debian and RPM repositories.
- minikube.sigs.k8s.io for minikube docs, and github.com/kubernetes/minikube/releases and storage.googleapis.com/minikube for minikube downloads.
- The exact package names the docs give:
Kubernetes.kubectlandKubernetes.minikubeon winget,kubernetes-cliandminikubeon Chocolatey,kubectlon Scoop,kubectl,kubernetes-cliandminikubeon Homebrew.
If a page offers a "kubectl installer" with a setup wizard, close it. The Kubernetes Windows page offers only the binary and the three package managers above.
kubectl plugins are separate programs
A plugin is any executable on your PATH named kubectl- something. kubectl foo runs kubectl-foo with your environment, including your kubeconfig. The Kubernetes plugins page says Krew plugins "are not audited for security" and that you run third party plugins "at your own risk, since they are arbitrary programs running on your machine." To see what is on your PATH, including warnings about overlapping names:
kubectl plugin list
More in are kubectl plugins safe to install. Since Kubernetes 1.26, kubectl has no built in authentication for some managed Kubernetes services, which ship their own plugins instead. If you see "No Auth Provider Found," get the plugin from the cloud provider's own documentation.
kubeconfig hygiene
Your kubeconfig holds cluster addresses and often credentials. Treat it like a private key.
The Kubernetes kubeconfig page warns: "Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure." If someone sends you one, inspect it first, "much as you would a shell script."
By default kubectl reads $HOME/.kube/config. If KUBECONFIG is set, kubectl merges every file listed (colon separated on Linux and Mac, semicolon separated on Windows). The --kubeconfig flag uses exactly one file. To see what is in effect and switch explicitly:
kubectl config view --minify
kubectl config use-context minikube
A common accident is running a command meant for minikube against a production context left active earlier. Check the context before anything destructive, or keep a separate kubeconfig per environment.
- Add
.kube/and any kubeconfig files to your global gitignore. Never paste one into chat or an issue. - On Linux and macOS, make sure only your user can read
~/.kube/config. minikube keeps its cluster files in.minikubein your home directory, which deserves the same protection. - Keep kubectl's cache under your home directory. CVE-2019-11244 in the official CVE feed described
kubectl --http-cachepointed at a world accessible directory creating world writable cache files.
Keeping kubectl and minikube current
kubectl handles credentials and unpacks data from clusters, so it gets security fixes. A recent example from the official Kubernetes CVE feed: CVE-2026-19444, published 10 August 2026, a path traversal in kubectl cp on Windows. A malicious tar inside a container you copy from could make kubectl write files to arbitrary paths on your machine. Affected: v1.34.0 to v1.34.11, v1.35.0 to v1.35.8 and v1.36.0 to v1.36.4. Fixed: v1.34.12, v1.35.9, v1.36.5 and later. The advisory rates it Medium (CVSS 6.5) and says only Windows clients are affected. Earlier kubectl cp CVEs in the feed (CVE-2018-1002100, CVE-2019-11249, CVE-2019-11251) show it is a recurring area.
kubectl from pkgs.k8s.io
Patch releases arrive with normal updates (sudo apt-get update then sudo apt-get upgrade, or dnf update, or zypper update). A new minor version is a deliberate step. The Kubernetes page "Changing The Kubernetes Package Repository" says to edit the repository file and change the version:
nano /etc/apt/sources.list.d/kubernetes.list
deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.37/deb/ /
For yum, change the version in both the baseurl and gpgkey lines of /etc/yum.repos.d/kubernetes.repo. To check what a machine uses:
pager /etc/apt/sources.list.d/kubernetes.list
cat /etc/yum.repos.d/kubernetes.repo
If you see apt.kubernetes.io or yum.kubernetes.io, that machine has had no kubectl update from the project since September 2023.
kubectl from the binary or a package manager
Repeat the download, checksum and signature steps with the new version, or use your package manager's upgrade. Then run kubectl version --client on every machine you care about, especially on Windows with Docker Desktop.
minikube
minikube update-check
This prints the current and latest version. To upgrade, rerun your platform's install command with the checksum step, or upgrade through Homebrew, winget or Chocolatey. An old minikube eventually cannot start a supported Kubernetes version without --force. The kubectl that minikube kubectl -- downloads is managed by minikube, not your system package manager.
Where to watch for fixes
The Official CVE Feed lists CVEs announced by the Kubernetes Security Response Committee, in JSON and RSS:
curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json
curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/feed.xml
The Kubernetes security page also points to the kubernetes-security-announce group for email alerts. For minikube, watch its GitHub releases.
How to uninstall kubectl and minikube cleanly
Neither project has an uninstall page, so these steps undo what the install commands above created.
Delete clusters before removing the binary, or you leave VMs and containers behind:
minikube delete --all --purge
--all deletes all profiles and --purge deletes the .minikube folder in your home directory. Then remove minikube itself: delete /usr/local/bin/minikube, uninstall the Homebrew formula or the .deb or .rpm package, or on Windows uninstall with winget or Chocolatey, or delete C:\minikube and remove it from PATH.
For kubectl, delete /usr/local/bin/kubectl or ~/.local/bin/kubectl, or uninstall with the package manager you used. On repository installs, also delete the files the install created: /etc/apt/sources.list.d/kubernetes.list and /etc/apt/keyrings/kubernetes-apt-keyring.gpg, or /etc/yum.repos.d/kubernetes.repo, or /etc/zypp/repos.d/kubernetes.repo. A stale repository is a trusted source you have forgotten about.
Finally, ~/.kube holds your kubeconfig and cache. If it has credentials for other clusters you still need, remove only the minikube entries. If the machine is being retired, delete it and revoke those credentials on the cluster side; deleting a file does not revoke the token or certificate inside it.
Common errors and how to fix them
"The connection to the server ... was refused"
The install pages show this for a kubectl that is not configured or cannot reach a cluster. When the server named is localhost:8080, kubectl found no kubeconfig with a cluster and fell back to its default. Start your cluster (minikube start), check kubectl config view --minify shows the context you expect, and check KUBECONFIG is not pointing at a missing file. If kubectl cluster-info returns a URL but things still fail, the docs suggest kubectl cluster-info dump.
Version skew warnings
If kubectl warns that it differs from the server by more than one minor version, install a kubectl inside the window or use minikube kubectl --. On repository installs, the repo file usually still names an old minor version.
"kubectl: FAILED" on the checksum
Usually the binary and checksum came from different versions because stable.txt changed between downloads, or the architectures differ. Pin the version in both URLs and retry. If it still fails, delete both files and do not install.
minikube cannot find a driver
The start page sends you to the drivers page. Check that Docker is running, Hyper-V is enabled or virt-host-validate passes, then pass --driver explicitly. A permission error on the Docker socket means your user cannot reach Docker; decide deliberately between the docker group and rootless Docker.
Not enough CPUs or memory
The start page requires at least 2 CPUs and 2GB of free memory. Change the memory default (needs a restart):
minikube config set memory 9001
The FAQ also documents minikube start --memory=max --cpus=max. With the Docker driver, Docker Desktop's own resource limits apply, so raise those first.
Debugging minikube itself
minikube start --alsologtostderr --v=2
minikube logs
Where Safeguard fits, honestly
Safeguard does not install kubectl or minikube, check their checksums or signatures, or inspect your kubeconfig. Everything above works without it. The link is what you deploy once the cluster runs: container images carrying operating system packages and application dependencies with their own known vulnerabilities.
Safeguard scans the container images you build and deploy (for example safeguard scan --image with an image name from the CLI, with results written as JSON under ./output), produces SBOMs for them, matches components against vulnerability databases and shows which projects contain a given component and version. Reachability analysis ranks the vulnerable code your application actually calls. With autonomous remediation switched on (it ships off by default), it can open fix pull requests that bump a base image or dependency. Safeguard's attestation and signing support covers Sigstore keyless signatures and SLSA provenance, with Kubernetes admission control to check them at deploy time; see getting started with Safeguard Kubernetes admission. For access control inside the cluster, read how to set up Kubernetes RBAC.
What Safeguard does not do: judge whether a kubectl plugin or a downloaded binary is trustworthy, or replace the checksum and signature checks in this guide.
Common mistakes
- Following a tutorial that adds apt.kubernetes.io. It went away in March 2024. Use pkgs.k8s.io.
- Setting
gpgcheck=0or droppingsigned-byto get past an error. That disables the check that makes the repository route safe. - Mixing versions of binary and checksum. Pin both URLs to the same version.
- Trusting a checksum from the same lookalike site as the binary. Use dl.k8s.io and the cosign check.
- Copying an old cosign command without the identity and issuer flags. Current cosign requires them, and they tie the signature to the Kubernetes release pipeline.
- Letting the repository's minor version fall behind the cluster. You drift out of the skew window as the cluster upgrades.
- Assuming the kubectl on PATH is the one you patched. Check with
kubectl version --client. - Installing Krew plugins or opening an emailed kubeconfig without reading them. Both run with your credentials.
FAQ
How do I install kubectl on Windows 11?
winget install -e --id Kubernetes.kubectl is the quickest official route. To verify the file yourself, download kubectl.exe and its .sha256 from dl.k8s.io with curl.exe, compare them with Get-FileHash, add the folder to PATH and run kubectl version --client. Make sure Docker Desktop's kubectl is not earlier in PATH.
How do I install kubectl on Ubuntu?
Add the pkgs.k8s.io apt repository with its key in /etc/apt/keyrings and signed-by in the repository line, then sudo apt-get update and sudo apt-get install -y kubectl. Or download the binary from dl.k8s.io, check its .sha256 and install it to /usr/local/bin.
How do I install kubectl on a Mac?
brew install kubectl. For a verified binary, download the darwin arm64 or amd64 build from dl.k8s.io, check it with shasum -a 256 --check and move it to /usr/local/bin.
Do I need to install kubectl separately if I use minikube?
No. minikube can download a matching kubectl and run it as minikube kubectl --. A separate kubectl is better if you also work with other clusters.
How do I verify kubectl is genuine?
Check the .sha256 from dl.k8s.io, then run cosign verify-blob with the identity pinned to krel-staging@k8s-releng-prod.iam.gserviceaccount.com and the issuer to https://accounts.google.com.
Why does apt fail on the Kubernetes repository?
If the repository line names apt.kubernetes.io, it points at a repository that went away on 4 March 2024. Replace it with the pkgs.k8s.io line for your minor version and download the key from pkgs.k8s.io.
Which minikube driver should I use?
The preferred one for your OS: Docker or KVM2 on Linux, Docker or VFkit on macOS, Hyper-V or Docker on Windows. The VM drivers give a stronger boundary; Docker is easiest if it is already installed.
How do I update or uninstall minikube?
minikube update-check compares your version with the latest; rerun the install command or upgrade through your package manager. To remove it, run minikube delete --all --purge, then delete the binary or package.
Is minikube safe to use for production?
No. The minikube FAQ says the project strongly discourages production use or listening to remote traffic.
Fix it without waiting for upstream
A local cluster is where your images and their dependencies first run on Kubernetes. Patching kubectl and minikube is the easy part; the bigger exposure is the open source inside what you deploy, and how quickly fixes reach it.
Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.
1. Autonomous remediation: pull requests, not tickets
When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.
2. Gold Open Source: the safe version in seconds, free
gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.
3. Gold Registry: start from components that are already fixed
registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.
When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.
| Your situation | What to use |
|---|---|
| A fixed version exists | Autonomous remediation opens the upgrade pull request; Gold Open Source confirms the safe version |
| You need to know today whether you are affected | Gold Open Source lookup and "Am I affected?" checker, free and without login |
| You want vulnerable versions to stop shipping | The Gold scan GitHub Action in CI, plus Safeguard policies and gates |
| Upstream has no fix yet, or will not ship one | A custom Gold request; fork and patch (early access) |
| You want to start clean on new projects | Pull hardened components and images from Gold Registry |
One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.
See how Safeguard would help
None of these demos install kubectl or minikube. They show what happens after, when the applications and images you deploy start pulling in dependencies. To try the CLI yourself, download it from https://safeguard.sh/download and follow the setup guide at https://docs.safeguard.sh/docs/cli .
The first demo is a real CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same approval flow applies to an application you are about to build into an image and deploy to minikube.
Click through it at your own pace, or open it full screen.
The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and then scans from the terminal. On the workstation where you run minikube, that is how you would scan local projects and the images you load into the cluster without sending source code elsewhere; see how the local runner and offline mode work.
Click through it at your own pace, or open it full screen.
The third demo shows the desktop app sending work to a computer running the CLI, with each command approved before it runs. If you are standardising kubectl and minikube installs across a team, it keeps a person in charge of every command that touches a developer or build machine.
Click through it at your own pace, or open it full screen.
Quick check
Why is a matching .sha256 file not enough on its own to trust a kubectl binary?
Because a checksum only proves the file matches the hash published beside it. A lookalike site can publish a fake binary with a matching fake hash. The cosign signature, verified with the identity pinned to the Kubernetes release service account and Google's OIDC issuer, proves the Kubernetes release process produced the file.
Your cluster runs Kubernetes 1.37. Which kubectl versions are supported against it?
1.36, 1.37 and 1.38. The Kubernetes version skew policy supports kubectl within one minor version, older or newer, of the API server.
Sources
- Kubernetes Docs: Install Tools
- Kubernetes Docs: Install and Set Up kubectl on Linux
- Kubernetes Docs: Install and Set Up kubectl on macOS
- Kubernetes Docs: Install and Set Up kubectl on Windows
- Kubernetes Docs: Verify Signed Kubernetes Artifacts
- Kubernetes Docs: Version Skew Policy
- Kubernetes Docs: Changing The Kubernetes Package Repository
- Kubernetes Blog: pkgs.k8s.io, Introducing Kubernetes Community-Owned Package Repositories
- Kubernetes Blog: Kubernetes Legacy Package Repositories Will Be Frozen On September 13, 2023
- Kubernetes Docs: Organizing Cluster Access Using kubeconfig Files
- Kubernetes Docs: Configure Access to Multiple Clusters
- Kubernetes Docs: Extend kubectl with plugins
- Kubernetes Docs: Official CVE Feed
- Kubernetes: Official CVE Feed (JSON)
- Kubernetes Docs: Kubernetes Security and Disclosure Information
- Kubernetes: stable release version
- Kubernetes: pkgs.k8s.io v1.37 Debian repository Release.key
- minikube Docs: minikube start
- minikube Docs: Drivers
- minikube Docs: docker driver
- minikube Docs: hyperv driver
- minikube Docs: kvm2 driver
- minikube Docs: vfkit driver
- minikube Docs: Kubectl
- minikube Docs: FAQ
- minikube Docs: Troubleshooting
- minikube Docs: minikube delete
- minikube Docs: minikube update-check
- minikube on GitHub: v1.39.0 release
- Sigstore Docs: Cosign installation
- GnuPG manual: Operational GPG commands
Last reviewed: 23 October 2026. Kubernetes and minikube versions, supported drivers and repository details change with each release; check the linked official pages before you install.