I'm using Splunk Enterprise 8.2.5 on Windows and using deployment server to push apps. There is currently no indexer configured in /etc/system/local/outputs.conf as we do all this in the app. Our security team want our forwarders to start shipping up the events over TLS 1.2. As a quick test I have the following with non-deployment server app:
This works fine but now I have the issue of how to deploy apps from deployment server. If I use the default, a self-signed or PKI signed client cert at the forwarder I must secure the private key with a password and specify that password in the outputs.conf. Therefore if specifying the indexer for a given app (not all apps have the same indexer!) I need to specify the password for that app in the <app>/outputs.conf file at the deployment server. I tested this but one issue is the password does not get encrypted on the deployment server or the target UF.
I'd realistically needs the same client certificate on all forwarders to make this manageable.
Should I be defining all indexers outside of deployment server apps in /etc/system/local/outputs.conf and then routing to them in the <app>/outputs.conf instead?
Note: Although it states here that if the password is specified in a conf file outside /etc/system/local/ it will not be encrypted I have tested and it is! This whole area of config is very confusing IMO 😞
Managing certificates is always a pain in the well-known body part.
Technically, you can of course use the same key/cert pair for all forwarders (or even all your splunk components) but that's simply not how the PKI is supposed to work.
So I'd say manage your certificates by the same means you normally manage your infrastructure but keep the cryptographic material in the same place on all forwarders and just push a config containing the main outputs config along with the location of the files but leave the key/cert file and possibly passphrase management to the normal OS management process. I'd even go as far as to say that it's pretty sufficient to leave the key file passwordless and just limit access to the file by means of file permissions. This way you don't have to worry about the password encryption in config. Yes, I know it's a potential weakness but I can live with that. If someone is able to access the key file, he's able to decrypt the password as well anyway.
if you configure an app (called e.g. TA_Forwarders) containing two files:
You can deploy them using a DS.
if you put a password in outputs.conf, at the first deploy it's encrypted and the outputs.conf file is moved from default folder to local folder.
In this way you'll never have clear text password for the connection to Indexers in SSL.
Thanks for the reply. 🙂 I have some comments:
I answer to your questions:
1) I always put deploymentclient.conf in the TA_Forwarders because in the future there could be the necessity to change the Deployment Server and I want to avoid to manually modify each deploymentclient.conf!
2) as I said you should create an app called e.g. TA_Forwardersto deploy using the Deployment Server, in this app you should put (in the default folder or in the local folder) outputs.conf and deploymentclient.conf.
if you created in the default folder, at the first deploy, outputs.conf is created in the local folder containing the encrypted password.
If instead you created in the local folder, the password is only encrypted at the first deploy.
I'm meaning encrypted in the destination system.