SSL and Port Questions


#1

Hi Everyone,

Just got my Metabase installed using the jar file on an ec2 instance (Our VPC config is too complicated for me to understand so EB wasn’t a great option).

EDIT: The ec2 instance is Ubuntu 16.04, Chrome 71.0.3578.98, and Metabase v0.31.2

A few questions:

  1. I used
    keytool -genkey -keyalg RSA -alias tomcat -keystore selfsigned.jks -validity 2 -keysize 4096
    to generate my .jsk file.

Was this the correct way to do it?

  1. I added the following commands to my .bashrc file
export MB_PASSWORD_COMPLEXITY=strong
export MB_PASSWORD_LENGTH=16
export MB_JETTY_SSL="true"
export MB_JETTY_PORT="80"
export MB_JETTY_SSL_Port="80"
export MB_JETTY_SSL_Keystore="~/metabase/selfsigned.jks"
export MB_JETTY_SSL_Keystore_Password="********"
  1. After I first did MB_JETTY_SSL=“true”, I started getting permission denied errors. I tried to undo with MB_JETTY_SSL=“false” but that didn’t work:
Launching Embedded Jetty Webserver with config:
 {:port 3000, :ssl? true}

01-22 23:53:45 ERROR metabase.core :: Metabase Initialization FAILED
java.net.SocketException: Permission denied

I added my key, and still got the same error. Added sudo in front of ‘java -jar’ and it worked.

  1. Now, I can run sudo java -jar etc. but I can still only connect at http://host:3000. host:80 does not work, https does not work. I believe I followed the correct instructions but am a little bit lost.

Thank you!


#2

Hi @tsangha

I’m pretty sure that you need to run things as sudo to be able to use ports <1024
Both MB_JETTY_PORT and MB_JETTY_SSL_PORT uses port 80 - shouldn’t that be 80 and 443 ?
And you need to define MB_JETTY_HOST too, since it defaults to localhost.
Have a look at the configuration options: https://www.metabase.com/docs/latest/operations-guide/start.html#customizing-the-metabase-jetty-webserver

But I would highly recommend that you use a reverse-proxy like Nginx or Caddy instead.
It can be setup in a breeze and then it can also handle certificates via LetsEncrypt.
https://github.com/metabase/metabase/issues/4558#issuecomment-372215880
https://github.com/tlrobinson/metabase-proxy-examples


#3

Thanks @flamber, that was a lot of helpful information. If you have a couple minutes I have a few more questions:

  1. sudo export isn’t a thing. Do I need to configure things on the AWS side to allow inbound connections to that ec2 instance on both 80 and 443? My ubuntu user generally speaking has sudo permissions though.
  2. How should I configure MB_JETTY_HOST? I’m trying to use this as a production deploy of Metabase. In order to access the ec2 instance, users need to be connected to our corporate VPN. So, by running things on localhost, I was going to just send people to 172.30.0.1:80 or whatever the ec2 ip address is within our network. Is there a better way of doing this? I verified that running on localhost was accessible to other logged-in VPN users via their browsers.
  3. I’m looking at that github issue you linked, #4558, and it seems there are still some recent bugs involving the reverse proxy. Can you please explain a little bit about why it’s recommended? Is it for security purposes? Requiring the VPN to connect to this ec2 seems like it should be sufficient? The reverse proxy would just act as an intermediary and show that traffic was coming from the proxy and not from my ec2 instance. Is that right?

#4

@tsangha

  1. I would guess you have to create a systemd service that sets the export variables before it then runs Metabase as an unprivileged user.
    https://www.metabase.com/docs/latest/operations-guide/running-metabase-on-debian.html
  2. I have no idea how AWS works, but you’re running Metabase on localhost - meaning 127.0.0.1 - which is different from 172.30.0.1, so you would need to define MB_JETTY_HOST if you want to use Jetty instead of a reverse-proxy.
  3. There’s no issues with doing reverse proxy. Yes, some people are having issues, but I don’t know their setup, so I cannot say if they are doing something wrong. And most people run Metabase in the root of their host, whereas the problems you’re reading are about running in a sub-dir.
    I would always always run things via a reverse-proxy, since Nginx/Caddy are better at handling connections (and security) than Jetty, so it just gives me more control.