SRM audit issue - st2config file might be required to remain on disk - any workaround?

[bro-relax]

Hello all!

We are currently going through an internal SRM audit for our implementation of stackstorm, and one of the issues that came up is the fact that the st2config file remains on disk with credentials (for redis, mongo etc) that are not encrypted.

To workaround this, we had developed a python script that would latch on to the st2ctl start/restart commands and would rebuild the config file with information retrieved in our Hashicorp vault - start the st2components - and then after 30 seconds, delete the config.

This works fine and we are able to rebuild the configuration when we manually start the service - however we are seeing that eventually, (after 24 hours), we see that st2auth/st2api eventually crashes, because it can no longer find the configuration file (i think after a log rotate, it restarts the service?)

I just wanted to verify with you guys if the config file is periodically read, and if there is any potential workaround to get st2config off the disk for security compliance - without us having to directly monkey patch a solution into the base code.

Thank you!

[arm4b]

Yeah, if you're on VM install, logrotate via config below might send a signal to StackStorm that probably leads to a configuration reload.

st2/conf/logrotate.conf

Lines 40 to 47 in 9abb54b

	## API
	/var/log/st2/st2api.log {
	daily
	rotate 5
	postrotate
	st2ctl reopen-log-files st2api > /dev/null
	endscript
	}

st2/st2common/bin/st2ctl

Lines 139 to 142 in 9abb54b

	for p in ${PID}; do
	echo "Sending SIGUSR1 to ${COM} PID: ${p}"
	kill -USR1 ${p}
	done

so yeah, try to dig deeper if it's logrotate.

[bro-relax]

This was it! We located the configurations in /etc/logrotate.d/st2 and are working towards rebuilding the configuration on log rotation. Thank you Armab!