operator 0.1.0 does not work when password is configured using defaults

[mikedickey]

Previous releases allowed you to specify secrets like splunk.password via defaultsUrl or defaults spec parameters. 0.1.0 assumes that the auto-generated admin passwords it creates in kubernetes are valid, so if you change it using defaults, upgrades, updates or scaling operations may fail.

One possible approach to fix this is adding a secretsRef to the IndexerCluster, SearchHeadCluster, LicenseMaster and Standalone CRDs. This would refer to a Kubernetes secret that includes one or more of the secrets used by the operator:

• hec_token
• password
• pass4SymmKey
• idxc.secret
• shc.secret

Any which are not defined would be auto-generated. This would provide a mechanism for users to provide their own secrets, but it would still fail when different ones are set via defaults.yml.

Another, more direct approach may be for operator to parse defaults. Currently it does not understand defaults and just passes these through to the container. Parsing the YAML and using it to override settings like secrets may be a more general purpose solution that can be reused to avoid other potential mismatch issues between these things.

Whatever approach we use, I think we should support the storage of these secrets in Vault, given its popularity.

[mikedickey]

Relates to splunk/splunk-ansible#511

[akondur]

Closing the issue with new implementation of password management.