The big picture:
Nine months ago we were granted an academic license for Search Guard and began a pilot project. This has gone well and the academic organization providing funding recently noticed that there is a market for what we do. The pilot system is going to be split into the existing academic effort and a commercial effort that will require paid licensing.
The system is a mix of Ubuntu 18.04 and Debian 9.9 that is going to converge on Debian 10 as time allows. We have OpenJDK 8 (8u222-b10-1ubuntu1~18.04.1) on two systems and the rest have OpenJDK 11 (11.0.4+11-1~deb10u1) on the rest. This will converge on OpenJDK 11 over the next month. We employ basic authentication and that is unlikely to change in the next year.
Our system is behind the Cloudflare CDN and this has worked well for us. We formerly had an Apache reverse proxy and someone familiar with that system. That person got busy and all the examples seem to be nginx, so we switched to that a few days ago.
Topology wise we have the following:
nginx proxy at 192.168.18.123 that handles all incoming traffic on 80.
kibana instance on 192.168.18.62 that is production.
kibana instance on 192.168.18.63 that can be used for testing.
nginx config is like so:
server {
listen 80;
server_name ls.netwarsystem.com;
access_log /var/log/nginx/ls.access.log;
location / {
proxy_pass http://192.168.18.62:5601;
}
}
server {
listen 80;
server_name zeno.netwarsystem.com;
access_log /var/log/nginx/zeno.access.log;
location / {
proxy_pass http://192.168.18.63:5601;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded$
proxy_set_header x-proxy-user admin;
proxy_set_header x-proxy-roles admin;
}
}
Current config:
sg_config.yml
http:
anonymous_auth_enabled: true
xff:
enabled: true
#being generous here, should be just 123 on the list, right?
internalProxies: ‘192.168.18.123|192.168.18.62|192.168.18.63|127.0.0.1’
#internalProxies: ‘.*’ # trust all internal proxies, regex pattern
remoteIpHeader: ‘x-forwarded-for’
proxiesHeader: ‘x-forwarded-by’
kibana.yml
searchguard.auth.anonymous_auth_enabled: true
elasticsearch.requestHeadersWhitelist: [“Authorization”, “sgtenant”, “x-proxy-user”, “x-proxy-roles”]
The problem(s):
And after that, things get a bit fuzzy. There are subtle differences between the 6.x configurations and 7.x - some attributes in 7.x have an underscore in their names, but this was not the case in 6.x. The goal here is that multiple remote web sites can embed a visualization in an iframe and have it accessible. The nginx proxy will have to add whatever is needed for Search Guard to determine appropriate permissions and serve up the content. This seems to be a bit different than how many users employ proxy auth.
I spent some time on this last spring, finally giving up and moving on to other tasks. Now we are at a point where this has to be solved. I am going to give one more focused try and if I can’t knock it off in the next week, I am going to be looking for someone who can consult and hour or two and make this do what we need.