A kubectl plugin is a standalone executable whose name starts with kubectl- and that sits somewhere on your PATH. The Kubernetes documentation says to install and run third-party plugins at your own risk, because they are arbitrary programs running on your machine, with access to the same cluster credentials you use.
Definition
kubectl discovers plugins by name. If you put a file called kubectl-foo on your PATH and make it executable, kubectl foo runs it. The command kubectl plugin list searches the PATH for valid plugin executables and shows what it finds. There is no manifest, no permission prompt and no sandbox. The plugin runs as you, with your environment, including KUBECONFIG.
The official page also notes a limitation that is useful for security: plugins cannot overwrite existing kubectl commands or extend commands other than create. A plugin cannot silently replace kubectl get, though a malicious binary elsewhere on the PATH is another matter.
What a plugin can reach
| Resource | Why a plugin can reach it |
|---|---|
| Cluster credentials | It inherits your kubeconfig and any exec credential helpers |
| Current context | It acts on whichever cluster your context points to, including production |
| Local files | Runs with your user account |
| Network | No restriction, so it can send data out |
| Other binaries on PATH | It can call them |
Because plugins are just files, "install" often means downloading a binary or a script from a repository and copying it to a PATH directory. There is nothing in the process that verifies where it came from.
A short vetting process
- Prefer source you can read. A script or a project with a public repository and a build you can reproduce beats a bare binary.
- Check who publishes it and how long the repository has existed. A fresh repository with one commit and a strong README is a flag.
- Read what it does with credentials. Does it call the Kubernetes API only, or does it also contact other hosts?
- For binaries, confirm the checksum or signature the publisher provides, and download only from the official release page.
- Pin the version. Record the version and checksum in your internal docs so a changed binary is noticeable.
- Test against a disposable cluster and a read only role first. Watch network connections while it runs.
- Put approved plugins in a known directory and keep that directory in your PATH ahead of anything user writable. Run
kubectl plugin listperiodically to see what else is on the PATH.
Reduce the blast radius
You do not have to trust every plugin with your administrator context. Use a separate kubeconfig with a read only identity for exploratory tools. Keep production credentials short lived. If a plugin only needs to inspect resources, run it with a role that can only inspect resources.
For team use, publish an approved list: plugin name, version, checksum, why it is approved, and who owns the review. The list also becomes your response plan if a plugin is later reported as malicious, because you know who has it.
Where Safeguard fits
Safeguard's SBOM and dependency scanning can inventory the libraries inside plugins you build in house, and its CLI can run in your pipeline before release. The free scan is at gold.safeguard.sh/scan.
Quick check
Does kubectl sandbox plugins?
No. Per the Kubernetes documentation they are arbitrary programs running on your machine, so they inherit your permissions.
How do I see which plugins are installed?
Run kubectl plugin list, which searches your PATH for valid plugin executables.
Sources
Last reviewed: 19 October 2026.
