Audit Docker plugins safely with docker plugin ls

You will list the Docker plugins visible to the local daemon, narrow the result by enabled state or capability, and choose an output format that is useful for a person or a script. These commands inspect state only: they do not install, enable, disable or remove a plugin. Allow about five minutes for a one-off check, or longer if you need to investigate a daemon or permission problem.

You need the Docker CLI and access to a running Docker daemon. The examples use an ordinary shell account. Docker access is security-sensitive because membership of the Docker socket's group can grant effective control over the host. Use sudo only when your Docker installation genuinely requires it, and do not add yourself to a privileged group just to make this command work.

1. Confirm the installed command

Start by checking which executable will run and which package supplied it. This matters when several Docker installations or wrapper scripts are present. On this machine the installed Docker Community Edition CLI is version 29.8.1.

$ command -v docker
/usr/bin/docker
$ dpkg-query -W -f='${Package} ${Version}\n' docker-ce-cli
docker-ce-cli 5:29.8.1-1~ubuntu.24.04~noble
$ docker plugin ls --help

The subcommand's synopsis is docker plugin ls [OPTIONS]. The manual page is for the installed command, so keep the version beside any captured output when you are comparing hosts or writing an operational record.

2. List every installed plugin

Run the command without a filter to see all plugins currently installed in the daemon's plugin store:

$ docker plugin ls
ID        NAME      DESCRIPTION   ENABLED

The table contains an ID, name, description and enabled state. The output above is the result on a daemon with no installed plugins. On a host with plugins, each plugin appears on its own row. An empty table is a valid inventory result, not proof that the Docker CLI is broken.

This command needs to contact the Docker daemon. If it reports that it cannot connect, check the daemon's service and socket configuration through your normal administration process. If it reports permission denied, first check your account's existing Docker access. Do not respond by changing socket permissions or granting broad privileges without an explicit security decision.

3. Filter by enabled state

Use --filter enabled=true when you need plugins that are active, or use enabled=false to find installed plugins that are currently inactive:

$ docker plugin ls --filter enabled=true
ID        NAME      DESCRIPTION   ENABLED
$ docker plugin ls --filter enabled=false
ID        NAME      DESCRIPTION   ENABLED

A filter returning no rows means that no installed plugin matches that condition. It does not enable or disable anything. Keep the filter value in the documented form, enabled=true or enabled=false; do not assume that a plugin name, image tag or arbitrary field is accepted as a filter.

4. Find a capability

Plugins can be filtered by capability. The installed command documents volumedriver, networkdriver, ipamdriver and authz as the supported capability values:

$ docker plugin ls --filter capability=volumedriver
ID        NAME      DESCRIPTION   ENABLED

Replace volumedriver with one of the other documented values when that is the capability you are checking. A capability filter is narrower than an enabled-state filter, so an empty result can simply mean that no installed plugin provides that capability. It does not tell you whether a plugin could provide a capability after installation, and it does not inspect a registry.

5. Choose output for people or scripts

The default table is convenient at a terminal. For a compact human-readable report, select particular documented fields with a Go template:

$ docker plugin ls --format '{{.ID}}: {{.Name}}'

The documented placeholders are .ID, .Name, .Description and .Enabled. The quoted template is passed to the shell as one argument. Keep the single quotes unless you deliberately need shell interpolation.

For machine-readable records, request JSON:

$ docker plugin ls --format json

With no matching plugins, this command prints no records. With plugins present, each record is JSON output describing a plugin. Treat the output as data rather than as a stable table layout. If you are building a script, validate the output with your JSON tooling and handle an empty result explicitly.

You can also combine a capability filter with a table template:

$ docker plugin ls --filter capability=volumedriver --format 'table {{.ID}}\t{{.Name}}'
ID        Name

The table prefix asks Docker to print column headings. Without that prefix, the same template prints only the rendered values. The --no-trunc option prevents truncated output, while --quiet or -q prints only plugin IDs:

$ docker plugin ls --quiet

Do not parse the default table by column position when a template or JSON output can express the fields you need. Descriptions and names may contain spaces.

6. Handle failures without changing plugin state

First separate a CLI problem from an inventory result. command -v docker checks the executable; docker plugin ls checks daemon access and plugin state. A non-zero exit status or an error message means the inspection did not complete, so do not interpret a blank-looking result as an empty inventory.

Common traps are using a capability name that is not one of the four documented values, assuming that enabled=false means a plugin is safe to remove, and running the command against a different Docker context than the one you intended. Confirm the daemon context using your established Docker administration procedure before recording the result. This guide does not change contexts, plugin state or daemon configuration.

There is nothing to undo after these examples because every command is read-only. If a later maintenance task installs, enables, disables or removes a plugin, treat that as a separate change: record the current inventory first, obtain the required approval, and keep a recovery plan for the service that depends on the plugin.