Smartstore configuration : How to encrypt volume definitions and use bundle deployment?

[emallinger]

Hello,
I would like to have confirmation of the best secure way to create smartstore volume (with access keys) : how will bundle validation behave if :?
- I declare volumes (with access_keys) in /opt/splunk/etc/apps/myvolumes/local/indexes.conf ON each indexers
- I push the indexes definitions (with those volumes) in /opt/splunk/etc/master-apps/myindexes/local/indexes.conf from the Cluster Master

Protocol would be : maintenance mode, stop every indexers, deploy new conf files via git (and finalize manually for the volume keys not to appear in git), validate bundle on the CM

=> Will it even work as there is no volume definition on the CM in /opt/splunk/etc/master-apps/myindexes/local/indexes.conf ?

There is something I do not understand : How am I supposed to secure (encrypt ?) the access keys in the cluster AND use the CM for bundle deployment ?

Thank you,

Ema

[emallinger]

Yeah, that I did already : and the access-key transmitted in the bundle are still clear and not encrypted on the Cluster Master AND on all the indexers.

It's not very satisfactory to keep it that way.

Hence me asking for suggestions.

Ema

[emallinger]

Hi again,

Is your sandbox clustered with a cluster master ?

Thanks,

Ema

[richgalloway]

My sandbox is not clustered, but that should not affect how the keys are stored.

You don't have to put all indexes in SmartStore so test it out with an index you create for that purpose.

[richgalloway]

Unlike pass4SymmKey, S3 access and secret keys are not stored in encrypted form.  That means you can deploy they keys from the CM without concern for how they will be saved on the indexers.

[emallinger]

Hello,

Seriously ?

Wow, that's weird...

Ema

[richgalloway]

Yes, I was serious, because the documentation says nothing about access keys being encrypted (unlike pass4SymmKey).

I took a look at one of my sandboxes, however, and see that remote.s3.access_key and remote.s3.secret_key are both encrypted.