(read in text mode to take out the extraneous formating done by the editor) 

Currently the customer is following this article to build out and deploy their AMQ Broker Operator with a connection to LDAP: https://access.redhat.com/solutions/6708231 . They have gotten some feedback from the security team that this is non-ideal due to the credentials being stored in the image. They'd like to have some additional fields exposed in the AMQ Broker Operator upon initialization so that they can avoid the multi-step process as well as avoid the credentials being stored in the image.

Using an init image requires hard-coding in credentials which is a security concern from the standpoint of the customer's security team.  The customer suggests

1. Exposing fields in the ActiveMQAtremis Custom Resource to allow Environment Variables to be populated from ConfigMaps and Secrests.

Perhaps just allowing the entries to be copied directly into the AMQ Broker StatefulSet:

 kind: ActiveMQArtemis
spec:
...
deploymentPlan:
env:
envFrom:

• secretRef:
  name: my-secret
• configMapRef:
  name: my-configmap

produces through the operator:

kind: StatefulSet
...
spec:
template:
spec:
containers:

• env:
  envFrom:
• secretRef:
  name: my-secret
• configMapRef:
  name: my-config

2) Similarly, Expose fields in the AMQ Custom Resource so that we can mount volumes from Secrets or ConfigMaps
The same suggestion, just allow something that gets directly copied from the Custom Resource to the StatefulSet.

The init-image already gives enough power to modify files and environment within the AMQ containers, so this seems like it doesn't compromise anything. You could instead allow init images to have these features so we could use a generic init image rather than one hard-coded per environment.