Security: Secret values materialized into cluster-scoped CRs (e.g. BMCSettings.spec)

[coderabbitai]

Problem

When dynamic settings are resolved via SecretKeyRef in the BMCSettingsSet controller, raw Secret values are copied directly into BMCSettings.spec.BMCSettingsTemplate.settingsMap — a normal, cluster-scoped custom resource field. This has several security implications:

• Downgraded confidentiality: Secret data benefits from Kubernetes RBAC and optional encryption-at-rest. Once materialized into a regular CR field, any principal with get/list access to BMCSettings can read the value without needing get on the source Secret.
• Confused-deputy risk: The controller's broad get;list;watch permission on secrets can be exploited to read arbitrary Secrets (cross-namespace) and persist their values into cluster-scoped CRs.
• Audit trail gap: Access to the secret value via the CR is not recorded against the originating Secret object.

This is a general pattern that may affect other controllers in metal-operator where SecretKeyRef-style sources are resolved and the resulting values are stored in spec fields.

Suggested mitigations

• Store only the reference (namespace/name/key) in the CR spec rather than the resolved value; resolve the value at apply time (e.g., in the BMC settings actuator) so it is never persisted.
• Constrain SecretKeyRef to the same namespace as the controller's service account and enforce this via webhook validation.
• Consider a dedicated SecretReference wrapper type in the spec that is explicitly marked as sensitive.

References

• Introduced in: Controller for BMC Dynamic settings #782 (discussion: Controller for BMC Dynamic settings #782 (comment))

/cc @stefanhipfel