Safeguard
Supply Chain Security•

How to Install kubectl and minikube Safely on Windows, Mac and Linux

Install kubectl from dl.k8s.io or pkgs.k8s.io and minikube from its official releases, check checksums and cosign signatures, then keep both patched.

Safeguard Security Team
33 min read

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.io and yum.kubernetes.io went 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 machinekubectl routeWhat gets verifiedMinor upgradesminikube route
Ubuntu or Debianpkgs.k8s.io apt repositoryapt checks every package against the repo keyEdit the version in the repo fileBinary or .deb
RHEL, CentOS, Fedorapkgs.k8s.io yum repositorydnf checks signatures with gpgcheck=1Edit the version in the repo fileBinary or .rpm
openSUSE or SLESpkgs.k8s.io zypper repositoryzypper shows the key fingerprint to acceptEdit the version in the repo fileBinary or .rpm
Any Linux, no root, CI, other distrosBinary from dl.k8s.ioSHA-256 plus cosignDownload the new binaryBinary
macOS, Apple silicon or IntelHomebrew or the darwin binaryBinary: SHA-256 and cosignbrew upgrade or new binaryHomebrew or binary
Windows 10 or 11winget, Chocolatey, Scoop or kubectl.exeBinary: SHA-256 via Get-FileHashPackage manager or new exewinget, Chocolatey or .exe
WSL 2The Linux route inside the distributionSame as LinuxSame as LinuxLinux 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

ArtifactIntegrity checkOrigin check
kubectl binary, any OS.sha256 on dl.k8s.iocosign .sig and .cert, identity pinned
kubectl from pkgs.k8s.ioPackage manager checks every packageRepo key from pkgs.k8s.io, scoped with signed-by or gpgcheck=1
Kubernetes release SBOMSHA-512 and SHA-256 filescosign signature
minikube raw binaries.sha256 on the GitHub releaseNone published
minikube .deb, .rpm, Windows installerNo .sha256 on the release page we checkedHTTPS 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.

OSPreferredAlso supportedExperimentalNotes
LinuxDocker, KVM2VirtualBox, QEMU, None, SSHPodmanDocker driver user can reach the Docker daemon, which is root equivalent
macOSDocker, VFkitVirtualBox, Parallels, VMware Fusion, QEMU, SSHPodman, KrunkitVFkit needs macOS 14 and minikube 1.36.0 or later
WindowsHyper-V, DockerVirtualBox, VMware Workstation, SSHQEMU, PodmanEnabling 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.kubectl and Kubernetes.minikube on winget, kubernetes-cli and minikube on Chocolatey, kubectl on Scoop, kubectl, kubernetes-cli and minikube on 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 .minikube in 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-cache pointed 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=0 or dropping signed-by to 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 situationWhat to use
A fixed version existsAutonomous remediation opens the upgrade pull request; Gold Open Source confirms the safe version
You need to know today whether you are affectedGold Open Source lookup and "Am I affected?" checker, free and without login
You want vulnerable versions to stop shippingThe Gold scan GitHub Action in CI, plus Safeguard policies and gates
Upstream has no fix yet, or will not ship oneA custom Gold request; fork and patch (early access)
You want to start clean on new projectsPull 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

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.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.