Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Credentials embedded in `endpointURL` are written in clear text to the instance sidecar logs

Aperta
  • Qualcosa non va?
#1,143 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend, security

Direzione di ricerca

Start by inspecting the v0.6.0 github.com/cloudnative-pg/barman-cloud call sites named in pkg/walarchive/cmd.go, pkg/backup/backup.go, pkg/command, and pkg/restorer/restorer.go. Reproduce the logging with an endpointURL containing userinfo, then verify all logged options redact the password while preserving URLs without credentials. Update the pinned library version in this repository after the library fix.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Description

When the endpointURL (or destinationPath) of an ObjectStore contains a password (https://user:password@host), the instance sidecar logs it in clear text. Every barman-cloud command it runs is logged with its full argument list, and --endpoint-url <value> and the destination path are part of that list.

The log calls are in github.com/cloudnative-pg/barman-cloud (v0.6.0, the version pinned by both v0.15.1 and main), not in this repository. I'm reporting it here because this is where users hit it, and the fix needs a change there and a version bump here.

Same family as #915, where the env slice was logged and #589 removed it. This path isn't covered by that fix.

What gets logged

Each of these logs options, the full command-line argument list, which includes --endpoint-url and the destination path:

Library call site Log message Level
pkg/walarchive/cmd.go (Archive) Executing barman-cloud-wal-archive, and the error that follows a failure info / error
pkg/backup/backup.go (Take) Starting barman-cloud-backup, Completed barman-cloud-backup, and arguments on bad arguments info / error
pkg/command/backupdelete.go Error invoking barman-cloud-backup-delete error
pkg/command/backuplist.go Can't extract backup id error
pkg/restorer/restorer.go WAL file not found in the recovery object store, Failed restoring WAL file info / warning
pkg/walarchive/cmd.go (CheckWalArchiveDestination) Executing barman-cloud-check-wal-archive, and the error after a failure trace / error

I observed the first three rows live (see below). The others are from reading the code: the same options slice is built the same way (--endpoint-url is added by CloudWalRestoreOptions, BarmanCloudCheckWalArchiveOptions and the list/delete builders) and then logged.

Impact

Low to medium, and it depends on credentials being placed in the URL, which the docs don't recommend (they use s3Credentials and similar secret references). But nothing prevents or flags it, and there are legitimate reasons for it, for example a basic-auth reverse proxy in front of an S3-compatible store.

When it happens:

  • the password is on every WAL archive line, so it is written many times a day, and repeated for as long as a retention or backup error persists;
  • the ObjectStore object already holds the value in clear text, but logs usually have a much wider audience (log aggregators, support bundles, shared dashboards) than whoever can read ObjectStore resources;
  • the log line is info level for the common ones (Executing barman-cloud-wal-archive), so it is not filtered out at the default log level.

I haven't checked whether botocore actually uses the userinfo part of the endpoint to authenticate. That doesn't change the finding: whatever value is configured is logged.

Proposed fix

Log a redacted copy of the options: mask the password in any URL-shaped argument (url.Redacted() from the standard library does this and leaves URLs without userinfo untouched), keeping the rest of the line, which is useful for debugging. A small helper in the library used by all the call sites above would cover them together and avoid each caller having to remember it.

Alternatives I considered:

  • Not logging the arguments at all. Simpler, but the argument list is useful to see what was actually run when a command fails.
  • Rejecting credentials in endpointURL at validation time. Stricter, but a behaviour change that breaks existing setups.

In the #1140 PR (recording the backup location in Backup.status.pluginMetadata), endpointURL and destinationPath are masked this way before being stored, so the behaviour would be consistent across the plugin.

I'm happy to send the PRs (library first, then the version bump here) once you tell me which shape you prefer.

How this was found

While live-testing the #1140 change on a local kind cluster (Kubernetes v1.37.0, CloudNativePG 1.30.1, cert-manager, RustFS as the S3 store), I created an ObjectStore with endpointURL: https://someuser:supersecret@object-store:9000 to check that the password does not end up in Backup.status.pluginMetadata. It didn't: the value there is https://someuser:xxxxx@object-store:9000. While checking logs for errors after the run, I searched them for the password and found it in the sidecar container.

I then read the library code at v0.6.0 to find where the lines come from, which is where the table above comes from.

Observed, on the plugin-barman-cloud container of the instance pod only: 94 log lines with the password after one cluster had archived WAL, taken one backup, and run its periodic retention pass for a while:

  • 6 × Executing barman-cloud-wal-archive (options[2]),
  • 1 × Starting barman-cloud-backup and 1 × Completed barman-cloud-backup (options[5]),
  • 86 × Error invoking barman-cloud-backup-delete (options[1]).

The last one came from my test setup: RustFS answered InvalidArgument to a ListObjectsV2 call in the retention pass for a destination with a sub-prefix, and the retention pass repeats that every retentionPolicyIntervalSeconds. That isn't part of this report, but it shows how often a persistent error repeats the line.

Example (jq-formatted, the value is a placeholder I used for the test):

{
  "level": "info",
  "msg": "Executing barman-cloud-wal-archive",
  "options": [
    "--gzip",
    "--endpoint-url",
    "https://someuser:supersecret@object-store:9000",
    "--cloud-provider",
    "aws-s3",
    "s3://backups/creds-in-url/",
    "pg-e",
    "/var/lib/postgresql/data/pgdata/pg_wal/000000010000000000000001"
  ]
}

Environment: the sidecar was built from main plus the #1140 change, which doesn't touch these paths. The library version is the same (v0.6.0) in v0.15.1 and main, so the released plugin has the same call sites. I didn't run the released sidecar against a URL with credentials, only read it.

To reproduce: create an ObjectStore whose endpointURL is https://user:password@<host>:<port>, enable WAL archiving on a Cluster that uses it, then run kubectl logs <pod> -c plugin-barman-cloud | grep password.

I used an AI assistant (Claude) to help find this, run the test and draft this issue, as the AI policy asks for disclosure.

Lingua principale
Go
Stelle
196
Fork
76
Merge medio
4g 13h
PR unite (30g)
19

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cloudnative-pg/plugin-barman-cloud

Tutte le issue di cloudnative-pg/plugin-barman-cloud

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.