Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#1,143 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
backend, security

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Go
Star
196
Fork
76
Merge trung bình
4 ngày 13 giờ
Pull request đã merge (30 ngày)
19

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của cloudnative-pg/plugin-barman-cloud

Tất cả issue của cloudnative-pg/plugin-barman-cloud

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.