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

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.

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.