I haven't run into a limit with trusted_hosts, though I only have 22 listed within my config. And by the way, I don't have our ELB IP's listed in wgserver.trusted_hosts for our trusted auth setup. Rather, what's listed is the IP's of the app servers that are calling to Tableau. And then the ELB IP's need to be listed in gateway.trusted. At least this is what worked for us. Within the gateway.trusted we have 2 IP's listed, one for the primary ELB and one for the failover ELB. Is it possible for your networking team to supply you VIP IP addresses that point at your ELB, perhaps this would be a more elegant solution rather than trying to list every individual IP of your load balancer setup which could change at any moment.
Just a word of warning--if you're trusting the IP of the ELB, you don't want any users to be able to hit the ELB directly with your setup, otherwise they can request their own tickets instead of the web app doing so on their behalf. Not secure! Are you using X-forwarded-for so that the IP of the web server is coming through, so you could just trust that instead?
Thank you for the answer.
From what I can see your web servers are reaching tableau server through the internal network.
Unfortunately we can’t have it (anymore)
We have set of conditions difficult to meet all together.
- 1. tableau trusted authentication between web server and tableau server is in use
- 2. requirement to have the full HTTPS communication with the customers side
- 3. requirement to have HTTP traffic at the server side
(for intrusion detection software client installed locally on the windows server)
We’ve managed to meet the three above as below:
As tableau needs to use single URL (same url for customers and the same usrl web server communication) HTTPS was required.
back through ELB in front of the tableau where HTTPS is decrypted to HTTP.
As the result tableau server https://tableau.domain.com is receiving requests from internal IPs of ELB.
When those IPs started changing – the whole idea colapsed.
You've hit it exactly in the point.
The question is: Is it possible to configure tableau and ELB so I could trust the IP of the web server?
That would be great solution.
For the moment once behind ELB - I see the ELB IP addresses generating the requests.
Ah, okay--so yes, I believe you should be able to do so. Have you see this: ?
In theory, using the X-Forwarded-For header should allow you to just trust the Web Server you've got, rather than the entire ELB.
we are using the X-Forwarded-For in our setup and it allows us to list the web servers in the trusted host, but then I think we still needed to list the ELB IP's in the gateway host. I can't remember the exact error we were getting, maybe a 502
However, my understanding is that you should not have to set the wgserver.trusted_hosts to include the IP of the load balancer, if you are using X-Forwarded-For. In fact you should never explicitly add the load balancer IP to the wgserver.trusted_hosts list unless you are using some kind of rule in your load balancer to enforce security, because otherwise, any client connecting through the load balancer can request and obtain a trusted ticket which, when redeemed, could allow them to access any view on your Server instance (even if they shouldn't have access).
Just wanted to clarify that...
Thank you for the help.
We will definitely change the design.
For today the web server is another AWS instance also behind another ELB ...
Taking in to consideration that the server's can't talk through internal network ...
it makes the entire solution too dynamic ...
because the IP of the web server is also changing randomly (because of ELB).
Hmm...if the web server IP is dynamic as well, it's definitely a no-go. Trusted tickets does require static IPs. Sorry, I wish I had another solution to propose!
What if you put the web hosts in a private subnet, with a nat instance? The Nat IP should never change. If you distribute your webservers across multiple azs, then you will have to add a nat instance to each private subnet in the azs. That should be enough to reduce the single point of failure issue.