List Docker Swarm Secrets Without Exposing Their Values

You will finish with a safe way to inspect Docker Swarm secret metadata, narrow the list by name or label, and produce output for a script without printing secret contents. Allow about ten minutes. You need Docker Engine access to a Swarm manager and the docker-ce-cli package. The examples were checked against Docker 29.8.1, package version 5:29.8.1-1~ubuntu.24.04~noble.

This command lists metadata only. It does not show the value stored in a secret, and it does not create, update or remove one. Keep that boundary in mind: a name, label or creation time can still reveal operational information, so treat the output as sensitive where your environment requires it.

1. Check the installed command

Confirm which Docker client is running and read the local command contract. This is an ordinary, read-only check and normally needs no elevated privileges:

$ docker --version
Docker version 29.8.1, build 4a63305
$ docker secret ls --help
Usage:  docker secret ls [OPTIONS]

List secrets

The command is docker secret ls. Its local manual page documents three options: --filter for narrowing results, --format for custom output, and --quiet for IDs only. The command belongs to Docker Swarm, not ordinary standalone-container administration.

2. Confirm that the client can reach a Swarm manager

Run the basic listing command from the Docker context you intend to inspect:

$ docker secret ls
ID                          NAME        CREATED        UPDATED
<secret-id>                 <secret-name>  <relative-time>  <relative-time>

The header and rows above show the shape of the result, not literal values to paste. A real list can be empty, and the exact columns or time wording can vary with the Docker release. Secret data is not printed.

Docker documents this as a cluster-management command that must run on a Swarm manager. On a worker, or on a host that is not participating in Swarm, expect an error such as:

Error response from daemon: This node is not a swarm manager.

That is a placement or context problem, not a reason to initialise a new Swarm. Do not run docker swarm init on a production host merely to make a read-only inspection command work. Switch to the approved manager or Docker context instead. If access to the daemon itself is denied, ask the host administrator to grant the required Docker access; adding your account to the Docker group is a security decision and is outside this guide.

3. Filter by a known name or ID

Use a filter when the manager contains more secrets than you need to inspect. Quote the whole key=value expression so the shell passes it as one argument:

$ docker secret ls --filter "name=payments"
ID                          NAME             CREATED        UPDATED
<matching-id>               payments-config  <relative-time>  <relative-time>

The documented name filter matches a full name or a name prefix. An ID filter also accepts a full ID or an ID prefix:

$ docker secret ls --filter "id=<secret-id-prefix>"

Replace the placeholder with a value copied from your own listing. Do not guess an ID, and do not put a secret value into a filter. If you need more than one condition, pass more than one filter flag:

$ docker secret ls --filter "name=payments" --filter "label=environment=production"

The supported label forms are a label key alone, such as label=environment, or a key and value, such as label=environment=production. Filtering changes what is displayed; it does not alter the secret or its labels.

4. Select output for a person or a script

For an operator's quick inventory, --quiet prints only secret IDs:

$ docker secret ls --quiet
<secret-id-1>
<secret-id-2>

This is useful as input to a later, deliberately reviewed command, but an ID is still an identifier for sensitive infrastructure. Do not feed it into a destructive command without checking the target first.

For stable field selection, use a Go template. The Docker documentation lists placeholders including .ID, .Name, .CreatedAt, .UpdatedAt and .Labels:

$ docker secret ls --format '{{.ID}}\t{{.Name}}\t{{.CreatedAt}}'
<secret-id>    <secret-name>    <relative-time>

The template is quoted with single quotes so the shell does not interpret the braces. For JSON lines, use the documented json directive:

$ docker secret ls --format json
{"CreatedAt":"<relative-time>","Driver":"","ID":"<secret-id>","Labels":"","Name":"<secret-name>","UpdatedAt":"<relative-time>"}

Treat this as metadata JSON, not as a way to retrieve a secret's value. If another tool consumes it, check that tool's error handling and avoid writing the output to a broadly readable temporary file.

5. Diagnose an empty or unexpected result

First rerun the unfiltered command against the same context:

$ docker secret ls
$ docker context show

If the unfiltered list is empty, check that you are on the expected manager and context, and that the names or labels you are searching for belong to Swarm secrets rather than environment variables, bind-mounted files or another Docker resource. A name filter is prefix-based, so a short or ambiguous prefix can return more than one row. An ID filter is also prefix-based.

If a template produces blank fields, check the placeholder spelling against the installed Docker documentation. Keep a plain table listing available while troubleshooting so you can distinguish a formatting mistake from a missing object. Do not use sudo automatically: it can select a different Docker configuration or context and can make you inspect the wrong daemon.

6. Keep the inspection reversible

Every command in this guide is read-only. There is no undo step because listing, filtering and formatting do not change Swarm state. The commands that would create, rotate or remove secrets are separate administrative operations and are intentionally not included here.