Remove Swarm API Key from Docs

[vallieres]

Description

Removing secrets from documentation.

Related issues or tickets

Reviews

• Technical review
• Editorial review
• Product review

[netlify]

✅ Deploy Preview for docsdocker ready!

Name	Link
🔨 Latest commit	90a21cd
🔍 Latest deploy log	https://app.netlify.com/projects/docsdocker/deploys/69baec78dc745c0008e5bb0f
😎 Deploy Preview	https://deploy-preview-24404--docsdocker.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[docker-agent]

Assessment: 🔴 CRITICAL

This PR modifies CLI reference YAML files in data/cli/engine/ that are vendored from the upstream docker/cli repository. According to project policy (see AGENTS.md), these files should not be edited directly in the docs repository.

Required action: These changes must be made in the upstream docker/cli repository first, then vendored back to the docs repository. Direct edits here will be overwritten on the next vendor sync.

The content changes themselves (removing real Swarm secrets and replacing with placeholders) are appropriate for security reasons, but they need to go through the correct upstream workflow.

[docker-agent]

🔴 CRITICAL: Editing vendored CLI reference file

This file is vendored from the upstream docker/cli repository and should not be edited directly in the docs repository.

According to AGENTS.md:

Content in _vendor/ and CLI reference pages generated from data/cli/ are vendored from upstream repos. Don't edit these files — changes must go to the source repository

Required action: Make this change in docker/cli first, then vendor it back to the docs repository. Direct edits here will be overwritten on the next vendor sync.

[docker-agent]

🔴 CRITICAL: Editing vendored CLI reference file

This file is vendored from the upstream docker/cli repository and should not be edited directly in the docs repository.

According to AGENTS.md:

Content in _vendor/ and CLI reference pages generated from data/cli/ are vendored from upstream repos. Don't edit these files — changes must go to the source repository

Required action: Make this change in docker/cli first, then vendor it back to the docs repository. Direct edits here will be overwritten on the next vendor sync.

[docker-agent]

🔴 CRITICAL: Editing vendored CLI reference file

This file is vendored from the upstream docker/cli repository and should not be edited directly in the docs repository.

According to AGENTS.md:

Content in _vendor/ and CLI reference pages generated from data/cli/ are vendored from upstream repos. Don't edit these files — changes must go to the source repository

Required action: Make this change in docker/cli first, then vendor it back to the docs repository. Direct edits here will be overwritten on the next vendor sync.

[docker-agent]

🔴 CRITICAL: Editing vendored CLI reference file

This file is vendored from the upstream docker/cli repository and should not be edited directly in the docs repository.

According to AGENTS.md:

Content in _vendor/ and CLI reference pages generated from data/cli/ are vendored from upstream repos. Don't edit these files — changes must go to the source repository

Required action: Make this change in docker/cli first, then vendor it back to the docs repository. Direct edits here will be overwritten on the next vendor sync.

[dvdksn]

@vallieres - see bot comment. This needs to be updated in the docker/cli repo upstream. But not sure why we need to change these?

[thaJeztah]

Do you know if the secrets detection on GitHub allows for patterns for example values? Ideally we'd still show a key with the same format and length; I recall there was a thread about that, but not sure what the outcome was (if github supported it)

[vallieres]

Do you know if the secrets detection on GitHub allows for patterns for example values? Ideally we'd still show a key with the same format and length; I recall there was a thread about that, but not sure what the outcome was (if github supported it)

Sadly it's not possible. The most we can do is provide negative lookahead regexp but it's easily getting out of hand if we start adding a rule for each token...

[vallieres]

@vallieres - see bot comment. This needs to be updated in the docker/cli repo upstream. But not sure why we need to change these?

These keep on triggering secrete scanning tools as they look like valid Swarm tokens. And since this is being replicated in a few other places, we easily 50+ notifications regularly. Trying to fix this at the source so we stop tripping the wire for these tools. I'll get the cli repo updated.

docker/cli#6867

[thaJeztah]

Do you know if the secrets detection on GitHub allows for patterns for example values? Ideally we'd still show a key with the same format and length; I recall there was a thread about that, but not sure what the outcome was (if github supported it)

Sadly it's not possible. The most we can do is provide negative lookahead regexp but it's easily getting out of hand if we start adding a rule for each token...

Yeah; I recall we discussed a separate prefix for demo purposes as alternative. I somewhat expected them to have some approach for that as it's not uncommon to have tokens for documentation or tests that should be ignored (not just these tokens)

Perhaps we can do something like SWMTKN-1-aabbccddeeff112233..... to closer match the expected format

[vallieres]

Do you know if the secrets detection on GitHub allows for patterns for example values? Ideally we'd still show a key with the same format and length; I recall there was a thread about that, but not sure what the outcome was (if github supported it)

Sadly it's not possible. The most we can do is provide negative lookahead regexp but it's easily getting out of hand if we start adding a rule for each token...

Yeah; I recall we discussed a separate prefix for demo purposes as alternative. I somewhat expected them to have some approach for that as it's not uncommon to have tokens for documentation or tests that should be ignored (not just these tokens)

Perhaps we can do something like SWMTKN-1-aabbccddeeff112233..... to closer match the expected format

If I use the same format, they will once again trigger the secret detection. The only way to skip over that is to "break" the pattern with something that does not fit the length and regexp.