Run internet-pi with SSL enabled

[klsgrtx]

Are there any instructions for adding an SSL cert to the mix so that this could be accessed via https?

[martinbrose]

I had a quick look and the following enables SSL.

I created a ssl key within the initial internet-pi folder:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -subj /CN=localhost -keyout internet-monitoring/grafana/provisioning/grafana.key -out internet-monitoring/grafana/provisioning/grafana.crt
chmod a+r ./internet-monitoring/grafana/provisioning/grafana.key

Added the following to the config.yml in the section '# Internet monitoring configuration.':

monitoring_grafana_ssl_file: /etc/grafana/provisioning/grafana.crt
monitoring_grafana_ssl_key: /etc/grafana/provisioning/grafana.key

And one more addition to templates/grafana-config.monitoring.j2:

GF_SERVER_PROTOCOL=https                                                                                                                                                                                                               
GF_SERVER_CERT_FILE={{ monitoring_grafana_ssl_file }}                                                                                                                                                                                  
GF_SERVER_CERT_KEY={{ monitoring_grafana_ssl_key }} 

Then just run the ansible-playbook again:

ansible-playbook main.yml -K

Enjoy!

[stale]

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

[KCapwell]

@martinbrose,
Thank you for the instructions for this request and on the documentation page.

Unfortunately, I have attempted to make your recommended changes on a RPi 4, with Debian GNU/Linux 11 and the most current version of Internet-Pi (June 11, 2022). However, try as I might -- I can not access the RPi at https://192.168.XXX.XXX:3030 nor https://192.168.XXX.XXX.

When I use 'netstat -antp' to see the ports that are being used by the Rpi 4 I see: 9798, 9115, 9100, 9090, 3030 and 22.

Furthermore, when you ask to edit config.yml and to add the following lines:

monitoring_grafana_ssl_file: /etc/grafana/provisioning/grafana.crt
monitoring_grafana_ssl_key: /etc/grafana/provisioning/grafana.key

The path: /etc/grafana/provisioning/ does not exist on my RPi 4 with Internet-pi. Those directories appear to be at ~/internet-monitoring/grafana/provisioning

It is very likely that I'm missing something obvious, since this is my first crack at Prometheus and Grafana. However, without your recommended changes, I can re-run the playbook and the RPi 4 works with https://192.168.XXX.XXX:3030. I've been running the non-https version for a week (at the time I write this).

FYI, personally I am not comfortable logging into a device via cleartext (read: http) where my credentials could potentially be sniffed.

Thank you.

[stale]

This issue is no longer marked for closure.

[martinbrose]

Hi @KCapwell,

I had a look and apparently I made a slight mistake in my instructions. Now corrected above.
The key files should be in the folder internet-monitoring/grafana/provisioning/ when you run the playbook.

Because when all the docker containers are being started up, this is the folder that gets mapped to /etc/grafana/provisioning/ within the Grafana docker container. This explains why you can't find that folder on your local Debian machine.

I also noticed that I received a permission error in the startup process of the Grafana container, so had to add chmod above. Don't think it's the most secure approach, but might be alright for the use case.

Hope this helps!

[KCapwell]

Hi @martinbrose,

Your recommended changes worked like a charm! Now I can access the site using https://192.168.XXX.XXX:3030. I am well aware that a self signed certificate is inherently less secure than a CA certificate. However, using Internet-Pi as an internal monitoring tool, I do believe that including the self signed certificate is one additional step towards best practices in InfoSec. I wouldn't recommend that typical "end user" get in the habit of blindly accepting a self signed certificate especially for external sites, but technical folks should comprehend the difference. That, along with the additional encryption for the authentication and other account credentials seems wise to yours truly.

Thank you!

[stale]

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

[stale]

This issue has been closed due to inactivity. If you feel this is in error, please reopen the issue or file a new issue with the relevant details.

[github-actions]

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

[github-actions]

This issue has been closed due to inactivity. If you feel this is in error, please reopen the issue or file a new issue with the relevant details.