💡 Summary

Allow for secretRefs for all sensitive values in the ThoriumCluster Custom Resource Definition.

Motivation and context

Currently, the only way to provide sensitive values to the ThoriumCluster resource is via plaintext in the manifest file. For example:

apiVersion: sandia.gov/v1
kind: ThoriumCluster
metadata:
  name: prod
  namespace: thorium
spec:
  ...
  config: 
    thorium:
      secret_key: "<SECRET>"

To set the value of the secret_key, we must provide the plaintext key. Instead, I propose we provide an option to read the value from a secret, similar to how envFrom works in Pod specs: https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container.

Implementation notes

Please provide details for implementation, such as:

This would be useful in continuous delivery solutions, such as ArgoCD, where kubernetes resources are defined in source control and are continuously deployed. In situations like this, it is not possible (or at least a very bad idea) to store the secret in plaintext. When used in conjunction with something like External Secrets Operator, the secrets' values themselves are never stored in source control, but rather the Secrets resources are created dynamically, and the Thorium operator would be able to read the value from the secret listed in the ThoriumCluster definition.

Acceptance criteria

How do we know when this work is done?

• secretRef is added as an optional configuration for each sensitive value in the ThoriumCluster custom resource definition