search

gravitational / teleport

The easiest, and most secure way to access and protect all of your infrastructure.
https://goteleport.com
GNU Affero General Public License v3.0
17.44k stars 1.74k forks source link

Agent joins the wrong port using https schema for `proxy_server` #30863

Open greedy52 opened 1 year ago

greedy52 commented 1 year ago

Expected behavior: Sample config:

version: v3
teleport:
  nodename: "iam_join"
  data_dir: "/var/lib/teleport"
  join_params:
    token_name: iam-token
    method: iam
  proxy_server: https://exmaple.teleport.com # without :<port>

Agent should join successfully to Proxy exmaple.teleport.com:443.

Current behavior: Agent attempts port :3080 and fails

2023-08-22T17:22:30Z DEBU [AUTH]      Registering node to the cluster. proxy-server:{example.teleport.com:3080 https } auth/register.go:256

Bug details:

Workaround: Specify :443 manually

webvictim commented 1 year ago

The other possibility is that we try both 443 and 3080 like tsh does when no port is provided, but this will make joining more complex. I think that technically as https: implies :443, using that port by default when the schema is provided would be a better idea.

greedy52 commented 1 year ago

I looked into this a little bit more.

There are a few other places making the assumption the default port is 3080 (e.g. public_addrs). And the defaults span multiple layers too (fileconf, servicecfg, etc). It will be a lot of work to update all of them to also check for https: schema.

Also, if we do change the default port to 443 for https:, it may break some existing environments where 3080 is expected.

Thus, instead of updating the default port based on https:, I am considering printing a warning when no port is provided. And in a few releases, maybe we can require the port to be always specified.

The other possibility is that we try both 443 and 3080 like tsh does when no port is provided, but this will make joining more complex.

I think this way is the most robust. But we will have to keep all our client implementations up-to-date.

zmb3 commented 10 months ago

-1 for trying both. I'd like to get away from that. Explicit with a clear error message is much easier to work with than "magic".

We have a lot of complicated behavior that's hard to test for due to the fact that we just try a bunch of things and hope that one works. It also creates a troubleshooting nightmare as we spit out error messages for all the things we tried.