Hi,

Thanks!

Well, currently there is no plan to implement such a thing.
I've no idea what a nice solution should be.
If you have don't hesitate to share with me.

I've already thought to one solution, but I don't know if it is stupid or not:

• generate a key : AES or DES... a cipher
• the key is used to encrypt the password with a custom tool (config phase)
• the encrypted password is stored in configuration file of the exporter.
• job in prometheus is configured to send a "auth_parameter" with a value set to the key.
• in the exporter the received auth_parameter is used to "decrypt" the stored password, each time it needs to authenticated to the server (session timeout).

I thing this solution has a minimal security: password is not in clear text, but since the traffic between prometheus and exporter is in clear text too, the key can be intercepted very easily. it is something like http "basic-authentication"... so encrypting is quite useless! Maybe in conjonction with a certificate for the http server of the exporter...

from veeam_exporter.

Hello :)

I didn't formulate the question clearly enough, sorry for that.
Communication between the Exporter and Prometheus hosts is not really the issue here as they are trusted 99% of the time (there are cases in a corporate environment, when the two are in different hands, but that's not that common and there are usually other safeguards in place). Of course securing protocols mitigate any obvious vulnerability. There are also tools for securing the sensitive info on the monitoring side.

What I was referring to is the fact that the config uses the PW in clear text to access the Enterprise Manager API and there is no cypher mechanism implemented in the code itself. When I tried the dry run, I noticed that the exporter also prints the credentials out when returning the metrics too.
And the user needs portal admin rights to access agent data too (other metrics run fine with read-only). This means if either the Exporter or the Monitoring side gets compromised, a bad actor could trigger restore jobs en-masse with the credentials.

It's not an issue in a home setup of course, but in the scope of enterprise environment would mean catastrophe.

A sensible solution would be putting an encrypted key in the config instead of the raw PW and implement a function for the tool where one can define a keystore with which it can then decrypt and connect to the Enterprise Manager.

I really like this tool (it's 100% in-line with the functionality we need) so I very much intend to use it on our productive system.

I will try to come up with a change which I would gladly share with you! I'm not that adept at py though (started learning not long ago), so it'll probably take some time.

from veeam_exporter.

Hi,

I noticed that the exporter also prints the credentials out when returning the metrics too.

you are right, but only in debug logging.

A sensible solution would be putting an encrypted key in the config instead of the raw PW and implement a function for the tool where one can define a keystore with which it can then decrypt and connect to the Enterprise Manager.

Well, it seems to me that the same thing but with one step more complex... if password to connect to the keystore is in config, reader of the file can connect to keystore and retrieve the cnx elements too. But... ;)

Greettings

from veeam_exporter.

Hi,

I had a busy day ! :-)

I've build a new branch : crypted_password for future 1.1.2
Read the README (bottom of the page) for configuration. (below an extract of new README)

Password encryption

There is no miracle solution since no user interaction is possible, including the launching time of the exporter.
This exporter now includes a basic method to crypt/decrypt password based a symetric 128 bits key (16 bytes) shared between prometheus and the exporter.

How it works:

• generate and store a 16 or 32 bytes password in your favorite password tool (keepass by example). It will be used as a shared secret key.
• use the provided tool to encrypt the password (passwd_crypt). It generates an encrypted base64 text.
• set the exporter config file with the encrypted password and set a property to inform the exporter that the password is encrypted.
• set the Prometheus configuration to add a parameter authkey set to the shared secret key to scrap the target.

The exporter config file now doesn't expose the password in clear text, and it can authenticate to the Veeam Server when it requires by decrypting the password with the authkey send by Prometheus.

The authkey is not kept by the exporter: it is received, used if login is required, then dropt. Same for the decrypted password: it is used to build the basic authorisation header then zeroed (but may remained in memory because of python immutable string...)

Most of the time, the exporter will use the authentication token received after a successfull login unless you set keep_session to false for the target. So decryption has a litle impact on performance.

Maybe can you have a look and tell me if it should do the job.
Don't hesitate if something seems unclear.
Depending on your feedback I would publish a new release.

from veeam_exporter.

Hello :)
apologies for the late response, things are complicated here atm.
It looks great, I'll update and try fiddling with it. I'll probably be able to give a feedback by the end of the week if that's okay.

from veeam_exporter.

Hi Jean-Francois,

so I tested the server side functions (without Prometheus), did some debugging with a colleague of mine and here are the findings.

for a dryrun on the Veeam Exporter host, the method in core_exporter.py doesn't get the authkey.

With the following changes in core_exporter.py, it works:

line 80: def login(self, auth_key):
line 85: if self.ns_session_login(auth_key) == self.SUCCESS:
line 97: def ns_session_login(self, auth_key):
line 102: login = self.api.login(auth_key)
line 141: if self.login(local_vars['authkey']):

I am not sure if this change would affect the process of the auth_key coming from Prometheus though....

I noticed that the encrypt_passwd script returns a different base64 string every run, with same encryption key. Is that intended? (dry run was successful with the key)

in the config:
instead of

    auth:
  # should be basic or encrypted
  type: encrypted

should be

    authmode:
  # should be basic or encrypted
  type: encrypted

With these changes, I was able to successfully connect to get the metrics from Enterprise Manager.

Also, an little additional note is that for Python script usage, the commands change:
python3 ./veeam_exporter_cmd &
python3 ./veeam_exporter_cmd -n -v -b /[veeam_exporter_folder] --config_file /[config folder]/config.yml
etc.

Perhaps it would be good to distinguish in documentation to avoid confusion.

I hope this helps, please have a look and let me know if there is anything else I should pay attention to.
Next step will be too hook Prometheus up. I will update accordingly. :)

Wish you a great evening!

Cheers,
Levente

from veeam_exporter.

Hi Levente,

Thanks for all you comments and tests.
for 1): argh... it is not the valid files that I've published... sorry. I'm not connected to internet (and github) at office for security reasons, so I have to juggle between several working directory trees. I will double check next time. but effectively the core_exporter.py in the repos is not the file I've on the "test" host.. Sorry for that.

for 2) that is perfectly normal: a part of the cipher are random bytes. it is the "normal" behavior and due to the aes implementation.
for 3) you are right: I will update the README. the conf/config.yml has the valid param but the doc is wrong. I will add the part to start from cmd line.

I will update the branch this week-end.
Many thanks.

JFPIK-

from veeam_exporter.

branch has been updated.
If you can have a look and reports me if you notice something wrong.
Else I will publish a new release next week.

JFPIK-

from veeam_exporter.

Hi Jean-Francois :)

is there any additional difference in code between the previous and this one aside from the ones mentioned above (in core exporter and the config)? If there is not, I don't think reinstall would be necessary, as it works confirmed (we still need to test the Prometheus side, but that's out of my hands unfortunately).

BR,
Levente

from veeam_exporter.

Hi,
No evolution at all, that you have already fixed.

from veeam_exporter.