Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port usage and webui vs auth service decoupling #2232

Closed
butsjoh opened this issue Sep 18, 2018 · 0 comments
Closed

Port usage and webui vs auth service decoupling #2232

butsjoh opened this issue Sep 18, 2018 · 0 comments

Comments

@butsjoh
Copy link

butsjoh commented Sep 18, 2018

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.

teleport:
  nodename: xxx
  data_dir: /var/lib/teleport
  pid_file: /var/run/teleport.pid
  advertise_ip: xxx.xxx.xxx.xxx
  connection_limits:
    max_connections: 100
    max_users: 5
  log:
    output: stderr
    severity: INFO
auth_service:
  enabled: "yes"
  cluster_name: "my_cluster"
  authentication:
    type: "local"
  second_factor: otp
  listen_addr: 0.0.0.0:3025
  public_addr: my.jump.host:3025
  session_recording: "node"
  client_idle_timeout: "1h"
  disconnect_expired_cert: no
  license_file: /var/lib/teleport/license.pem
ssh_service:
  enabled: "yes"
  listen_addr: 0.0.0.0:3022
  labels:
    role: jumpbox
    location: sentia
  commands:
  - name: arch
    command: [uname, -m]
    period: 1h0m0s
proxy_service:
  enabled: "yes"
  listen_addr: 0.0.0.0:3023
  web_listen_addr: 0.0.0.0:3080
  public_addr: my.jump.host:3080
  tunnel_listen_addr: 0.0.0.0:3024
  https_key_file: /a_privkey.pem
  https_cert_file: /a_fullchain.pem

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?

@butsjoh butsjoh closed this as completed Oct 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant