[CSPL-236] Implementation of Splunk Secrets override

[gjothikumar-splunk]

Addresses issue #53

• Implementation of Splunk secrets override through k8s secret
• An improvement to the current security model where secrets to be overridden are provided through defaultsUrl. Moving the override to k8s secrets is more secure
• The Splunk operator and Splunk Enterprise system all use the same secrets.

[Caldas]

Great @gjothikumar-splunk, it looks like fine .. just decreased too much the code coverage so more tests are required 🚀

[gjothikumar-splunk]

Great @gjothikumar-splunk, it looks like fine .. just decreased too much the code coverage so more tests are required 🚀

Thanks for the review @Caldas. I am still working on tests and will make sure coverage is maintained.

[gjothikumar-splunk]

We had a discussion on this and want to simply the whole secrets management and override in the operator. This is what we are thinking currently

• We will have a common set of secrets across all Splunk Enterprise components / CRs (indexer, sh, license master)
• If customer wants to override any secret and make all components use that the step would be to create a k8s secret called "splunk-secrets" and add the secrets to be overridden (pass4symmkey, password etc..) into that.
• The first CR that gets bootstrapped will look for "splunk-secrets", use the secrets form there and auto generate anything that does not exist there. All components will use the same set of secrets.

This will make secret management simpler, more predictable and also reduce unnecessary dependencies between components. This is a backward incompatible change and it will break the current deployments. At this early stages of the product, the cleaner way would be the following

• Before upgrade, create "splunk-secrets" with secrets to be used across the cluster.
• After upgrade the operator will use all secrets mentioned in "splunk-secrets" and generate the others. These should be used from thereon when interactig with Splunk Enterprise.

@mikedickey @kelvinatsplunk

[Caldas]

It's a great Idea !! Em ter, 21 de abr de 2020 16:18, Ganesh Jothikumar <notifications@github.com> escreveu:

…

We had a discussion on this and want to simply the whole secrets management and override in the operator. This is what we are thinking currently - We will have a common set of secrets across all Splunk Enterprise components / CRs (indexer, sh, license master) - If customer wants to override any secret and make all components use that the step would be to create a k8s secret called "splunk-secrets" and add the secrets to be overridden (pass4symmkey, password etc..) into that. - The first CR that gets bootstrapped will look for "splunk-secrets", use the secrets form there and auto generate anything that does not exist there. All components will use the same set of secrets. This will make secret management simpler, more predictable and also reduce unnecessary dependencies between components. This is a backward incompatible change and it will break the current deployments. At this early stages of the product, the cleaner way would be the following - Before upgrade, create "splunk-secrets" with secrets to be used across the cluster. - After upgrade the operator will use all secrets mentioned in "splunk-secrets" and generate the others. These should be used from thereon when interactig with Splunk Enterprise. @mikedickey <https://github.com/mikedickey> @kelvinatsplunk <https://github.com/kelvinatsplunk> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHFAPIN5R3Z5BHSICAXBVTRNXWPTANCNFSM4MKTW3VA> .

[smohan-splunk]

Closing this PR as it is outdated. Splunk Secrets updated implementation has been merged to develop
cc: @gjothikumar-splunk