docker-jitsi-meet
docker-jitsi-meet copied to clipboard
nginx: jvb websocket proxy avoid arbitrary redirect
This is intended to ensure the colibri-ws passthrough for the JVB websocket only goes to the proper location
Won't this break scalable infrastructure like K8s?
For example using multiple JVBs with one WS proxy won't work with these changes
Won't this break scalable infrastructure like K8s?
For example using multiple JVBs with one WS proxy won't work with these changes
This is true, I was considering only the docker-compose case. It may be that we need to have a few flags to control this behavior, since by default the regexp will forward to any IP, and any path, on port 9090. So likely if that's the desired behavior, we should have that behind a flag, and add something more restrictive for the default case. I'll work on something to that effect.
This curtails the default installation to a single JVB doesn't it?
Yes, it will restrict to a single JVB only.
There are two cases here.
- If someone is adding multiple JVB's at the same time(i.e at the time of deploying the setup).
- Adding JVB's dynamically(K8's, docker-swarm)
For Case 1: We have a workaround. We can set WS_SERVER_ID=jvb1,jvb2
and then split the WS_SERVER_ID
to get the list.
The below example is for demonstration purposes only.
# loop over ws_server_id_list
{ for videobridge in WS_SERVER_ID_list }
location ~ ^/colibri-ws/{{ videobridge }}/(.*) {
proxy_pass http://${videobridge}:9090/colibri-ws/${videobridge }/$1$is_args$args;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
tcp_nodelay on;
}
{ endfor }
will result in
location ~ ^/colibri-ws/jvb1/(.*) {
proxy_pass http://jvb1:9090/colibri-ws/jvb1/$1$is_args$args;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
tcp_nodelay on;
location ~ ^/colibri-ws/jvb2/(.*) {
proxy_pass http://jvb2:9090/colibri-ws/jvb2/$1$is_args$args;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
tcp_nodelay on;
I think this is how vanilla installation deploys multiple JVBs.
Case 2: Not possible without setting it like below
location ~ ^/colibri-ws/([a-zA-Z0-9-\.]+)/(.*) {
proxy_pass http://$1:9090/colibri-ws/$1/$2$is_args$args;
Couldn't one just allow a regex for the WS_SERVER_ID and carry the matched text over into the proxy_pass? I.e. just make what previously was ([a-zA-Z0-9-\.]+)
configurable.
An option could be to use proxy_bind (https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_bind) and set it to the IP address used to route packets to the JVB, thus limiting its scope to the internal meet.jitsi network.
That would break Kubernetes deployments right?
Couldn't one just allow a regex for the WS_SERVER_ID and carry the matched text over into the proxy_pass? I.e. just make what previously was
([a-zA-Z0-9-\.]+)
configurable.
It seems to me like this is the best path towards making this both configurable and secure-by-default. The current setting is too open for a default, while also being a valid configuration to choose when desiring to proxy to arbitrary JVBs. I believe we'll want to document the current value and suggest it to those folks deploying into larger environments (with caveats about its dangers too), while defaulting to a more locked down setup either via @saghul 's suggestion above of proxy_bind, or somthing based on my PR above.
Alternately, we could provide the above in the defaults as a new variable like WS_SERVER_REGEXP and and add an additional WS_SERVER_FROM_REGEXP boolean which defaults to false but can be simply set to true to re-enable the present behavior.
closing in favor of https://github.com/jitsi/docker-jitsi-meet/pull/1645