feat(s3): support SSE-C customer-provided keys

[schaurian]

Support S3 Server-Side Encryption with Customer-provided keys (SSE-C) in the ObjectStore resource. S3-compatible stores such as Hetzner Object Storage and some Ceph setups only offer SSE-C, so the bucket-managed encryption field cannot be used there.

The new sseCustomerKey field of s3Credentials is defined in the barman-cloud library and reaches the plugin through the embedded configuration. It references a secret holding a base64-encoded 256-bit AES key. The library keeps one key file per secret and passes it to every barman-cloud command that accepts it. barman-cloud-check-wal-archive only lists objects and rejects the option, so it does not get the key. The instance Role gets access to the key secret through the library helper SecretNames(), which replaces the plugin's own list of credential secrets.

An ObjectStore that sets sseCustomerKey together with data.encryption or wal.encryption is rejected at admission with a CEL rule, because barman-cloud refuses that combination at run time. The docs get a new section on SSE-C, including the need to keep the key safe and unchanged.

The e2e suite covers a replica cluster whose source and replica object stores use different SSE-C keys, each in its own secret. It checks that every object in each bucket is readable with its own key only.

Closes #646

---

Merge barman-cloud 0.7.0 before merging this PR.

[andrein]

Tested at adb7045 with main merged in for Barman 3.20.0, against a Ceph RGW
object store that supports only SSE-C, with CloudNativePG 1.30.0 and
cloudnative-pg/barman-cloud#284 at a300841.

Two changes were required:

1. sseCustomerKey is not collected by CollectSecretNamesFromCredentials, so
   the instance Role does not cover a key stored in its own Secret, as in the
   aws-sse-c docs example, and credential resolution fails with a forbidden
   error. fix: grant the instance role access to the SSE-C key secret schaurian/plugin-barman-cloud#1 against this branch adds it with a test.
2. The branch is based on v0.14.0, whose sidecar pins Barman 3.19.1;
   --sse-customer-key exists from 3.20.0, pinned on main since v0.15.0.

With those:

• key materialised in the sidecar and passed to every barman-cloud command,
  including backup-list and backup-delete
• WAL archiving continuous; objects report Encryption: SSE-C, 400 without the key
• base backup completed with Backup.status populated
• ObjectStore.status.serverRecoveryWindow populated
• retention applied on the primary
• recovery into a new Cluster through externalClusters[].plugin reproduced
  the source database

[schaurian]

Thanks for the end-to-end run and the RBAC fix, @andrein — merged schaurian#1 into this branch.

Updated the branch (eed228a):

• Rebased onto main, so the sidecar carries Barman 3.20.0 and the branch no longer conflicts.
• go.mod replace now points at the current head of feat(s3): support SSE-C customer-provided keys barman-cloud#284 (14f89b6), which includes your ValidateBackupConfiguration change.
• CRD, manifest.yaml and API docs regenerated with the repo's dagger tasks; the diff against main is exactly the new field.
• Docs: the SSE-C section no longer claims the field is independent of encryption — it now states that sseCustomerKey cannot be combined with data.encryption / wal.encryption — and the version note points at Barman ≥ 3.20.0 (sidecar since v0.15.0) instead of the barman issue.
• Added the new docs words to .wordlist.txt; spellcheck was the other reason the first CI run failed.

Local task ci on this head: commitlint, spellcheck, go test, uncommitted-drift check, docusaurus build and the ephemeral e2e suite (10 passed, 0 failed, 4 skipped — the GCS specs) all pass. golangci-lint reports only gomoddirectives for the temporary replace, which disappears once barman-cloud#284 is released and the replace is dropped.

One observation: the plugin does not call ValidateBackupConfiguration anywhere, so the new barman-cloud check does not currently guard ObjectStore objects — an object store with both sseCustomerKey and data.encryption is still accepted and fails at the first backup. The docs describe that behaviour. If you'd like it rejected at admission, I'm happy to wire the validation into the plugin in a follow-up.

[armru]

I pushed a few commits on top:

• main merged in, so the e2e runs on RustFS;
• the replace bumped to the new head of feat(s3): support SSE-C customer-provided keys barman-cloud#284;
• CEL rules on ObjectStore that reject sseCustomerKey together with data.encryption / wal.encryption at admission, with the docs updated;
• a replica cluster e2e where the source and the replica object stores use different SSE-C keys, each kept in its own secret. It checks that every object in each bucket is readable with its own key only.

That e2e is what found the check-wal-archive problem fixed in cloudnative-pg/barman-cloud#284: --sse-customer-key no longer reaches that command, and the combination with encryption is now rejected at admission instead of failing at run time. The PR description could be updated on both points.