Allow providing a user/pass combination to be used when running in Service Mode

[graza-io]

Current Issue:
It is currently difficult to automate against a Steampipe Service instance with external tooling on the basis that it generates a password when started in service-mode that must be extracted from the stdout or logs.

This means that someone must manually acquire this information in order to configure other tools to interface with the psql endpoint - (or you'd have to write a script to parse the output but this seems clunky).

Recommended Solution:
I think the most automatable approach would be to add args to the command used when starting up Steampipe in service mode.

Example
steampipe service start --user steampipe --pass s0m£SeCu|2€V4lu3!

Alternative Solutions:
An alternative I've considered which may also be useful when using the container based Steampipe would be to store the desired username and password as Environment Variables or in a configuration file in the .steampipe/ directory.

Additional Context:
The main reason for requesting this is that I would like to be able to automate a deployment of Steampipe and a few external tools which will interface with Steampipe via the psql endpoint created by it's service mode.

At the current time this requires the following steps:

• Deploy Steampipe in service mode and manually obtain credentials.
• Place credentials into secret engine (manually)
• Deploy other tooling using the information stored.

I would rather have all this automated so I can generate the credentials and deploy all of the services (Steampipe, etc) together all nicely automated.

[kaidaguerre]

@graza-io thanks for raising this, appreciate the time spent documenting potential options. I'll look into the best way of making this easier for your use case.

[graza-io]

@kaidaguerre I've been looking at the best way to handle this for my use-case, which turns out would be using Environment Variables for the container based Steampipe as I will likely be deploying this to a Kubernetes cluster.

However I feel if you include all 3 options suggested Env Vars, Command Args & Config file, with a defined order of precedence and fallback to current auto-generation in absence of all 3, this will cover off almost every potential use-case for people wishing to utilise the service mode of Steampipe.

[graza-io]

Hey @kaidaguerre,

I've looked into this a little more and based on the code Steampipe uses to configure the database, etc - it looks like it isn't worth the reworking to support allowing for a custom user (as defined in a lot of statements in db/local_db/install.go::installSteampipeDatabaseAndUser() as well as references to constants.DatabaseUser in various places).

However I feel it should still be feasible to implement being able to define a password for the steampipe user and have this overwritten in the service start command handler.