You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a question related to the coupling of the auth service and the webui. It might also be that we are understanding something wrong about the architecture of teleport and would like to have feedback on that. I am going to formulate our questions/observations based on an existing teleport configuration we have (obfuscated for private reason of course):
This is a configuration we have for a machine that is running with auth, proxy and role node.
In the documentation it clearly states that the actual recording is being shipped to the auth node (independent if we change the session_recording option) which ofcourse is the case but then we are wondering why the configuration of the webui part is done under the proxy service options. Logs stay at the auth server so why must you then configure it on the proxy? Also when you start a tsh session in the terminal it needs the webapi in order to authenticate. If for some reason you block port 3080 (which is configured under proxy) you cannot authenticate to the system.
I can agree with the fact that the proxy is the gateway into the system which in the end will communicatie with the auth server to get the certificate to connect further. But why is the webui so tightly coupled with the proxy public address? It would be awesome that the webui could be run on a different port then 3080 so tsh login could us the proxies web api to authenticate but the webui (to view recordings and hopefully soon as well the ssh events) can even be protected further if one would won't to put a firewall in front of that port. Today that seems to be impossible. If you need to authenticate (no firewall) then the webui needs to be public as well. It would be awesome if both could be split. Do you think this makes sense or are we not understanding something correctly?
The text was updated successfully, but these errors were encountered:
We have a question related to the coupling of the auth service and the webui. It might also be that we are understanding something wrong about the architecture of teleport and would like to have feedback on that. I am going to formulate our questions/observations based on an existing teleport configuration we have (obfuscated for private reason of course):
This is a configuration we have for a machine that is running with auth, proxy and role node.
In the documentation it clearly states that the actual recording is being shipped to the auth node (independent if we change the session_recording option) which ofcourse is the case but then we are wondering why the configuration of the webui part is done under the proxy service options. Logs stay at the auth server so why must you then configure it on the proxy? Also when you start a tsh session in the terminal it needs the webapi in order to authenticate. If for some reason you block port 3080 (which is configured under proxy) you cannot authenticate to the system.
I can agree with the fact that the proxy is the gateway into the system which in the end will communicatie with the auth server to get the certificate to connect further. But why is the webui so tightly coupled with the proxy public address? It would be awesome that the webui could be run on a different port then 3080 so tsh login could us the proxies web api to authenticate but the webui (to view recordings and hopefully soon as well the ssh events) can even be protected further if one would won't to put a firewall in front of that port. Today that seems to be impossible. If you need to authenticate (no firewall) then the webui needs to be public as well. It would be awesome if both could be split. Do you think this makes sense or are we not understanding something correctly?
The text was updated successfully, but these errors were encountered: