feat: hardened default SecurityContext for sidecar container

[ermakov-oleg]

Summary

Port of upstream #225

Problem: When no securityContext was specified in the Archive CRD, the sidecar container ran with no security restrictions (nil SecurityContext).

Fix: When securityContext is not explicitly configured, the plugin now applies a hardened default instead of nil:

• allowPrivilegeEscalation: false
• runAsNonRoot: true
• privileged: false
• readOnlyRootFilesystem: true
• seccompProfile: RuntimeDefault
• capabilities: drop ALL

Users can still override by setting securityContext explicitly in the Archive spec. All sidecar writable paths are already on volumes, so readOnlyRootFilesystem does not affect normal operation.

Disable pgbackrest file logging

pgbackrest writes logs to /var/log/pgbackrest/ by default. With readOnlyRootFilesystem: true this path is not writable, so every operation (backup, stanza-create, expire) produces a warning:

WARN: unable to open log file '...stanza-expire.log': No such file or directory

Added --log-level-file off to disable file logging. All pgbackrest output already goes through stderr into container logs.

Open question: is there a reason to keep file logging enabled? An alternative would be --log-path /controller/tmp to redirect logs to a writable dir.

[Agalin]

Good question about the file log. I'd say it's left here mostly because it didn't break anything in a read-only setup. We missed setting hardened defaults here because... our clusters already enforce those and inject secure defaults if missing. Although I wonder if hardcoding it like this still allows an override for people who'd like to redirect those logs to a PV for debugging. 🤔

I'm not sure about the approach, ideally we'd define defaults in the schema and separately for each security context entry. I'd need to check if kubebuilder enables doing so cleanly.