fix: Refuse to overwrite foreign objects from TrustStore reconciler

[dervoeti]

Description

TLDR: Write access on TrustStore allows write access for ConfigMap or Secret in the same namespace

The TrustStore reconciler writes its output ConfigMap or Secret using the TrustStore CR's own name and applies it via SSA with force=true. Combined with the operator's cluster-wide write permissions on ConfigMaps and Secrets, this lets any principal who can create a TrustStore in a namespace cause the operator to overwrite the contents of any pre-existing same-named ConfigMap or Secret in that namespace, stealing ownership and attaching a controller OwnerReference that links the hijacked object to the TrustStore CR for cascade delete.

A good showcase is the auto-published kube-root-ca.crt ConfigMap:
A tenant with create on truststores.secrets.stackable.tech in their namespace can create a TrustStore named kube-root-ca.crt, overwrite the CA bundle every pod in the namespace uses to verify in-cluster TLS, and cascade-delete that ConfigMap by deleting the TrustStore. This allows a) MITM attacks (hard because you need to modify DNS resolution of the Pods) and b) potentially crashing existing Pods on restart because kube-root-ca.crt is corrupted.

The same applies to any ConfigMap or Secret in the same namespace whose name the attacker can guess.

Fix

Before applying, look up the existing target. If the object already exists and is not owned by the current TrustStore, refuse the reconciliation.

Definition of Done Checklist

• Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
• Please make sure all these things are done and tick the boxes

Author

• Changes are OpenShift compatible
• CRD changes approved
• CRD documentation for all fields, following the style guide.
• Helm chart can be installed and deployed operator works
• Integration tests passed (for non trivial changes)
• Changes need to be "offline" compatible
• Links to generated (nightly) docs added
• Release note snippet added

Reviewer

• Code contains useful comments
• Code contains useful logging statements
• (Integration-)Test cases added
• Documentation added or updated. Follows the style guide.
• Changelog updated
• Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

• Feature Tracker has been updated
• Proper release label has been added
• Links to generated (nightly) docs added
• Release note snippet added
• Add type/deprecation label & add to the deprecation schedule
• Add type/experimental label & add to the experimental features tracker

[sweb]

lgtm - but I primarily did this to dive into the code base, so grains of salt - I also tried out the review skill on this.