Disabling Teleport in Gravity

In Gravity Community, it seems like Teleport is started, as the ‘gravity’ binary seems to bind to the normal Teleport ports (3022-3026):

tcp6       0      0 :::3022                 :::*                    LISTEN      10107/rootfs/usr/bi
tcp6       0      0 :::3023                 :::*                    LISTEN      22999/gravity
tcp6       0      0 :::3024                 :::*                    LISTEN      22999/gravity
tcp6       0      0 :::3025                 :::*                    LISTEN      22999/gravity
tcp6       0      0 :::3026                 :::*                    LISTEN      22999/gravity

However, there is no real way to interact or configure this Teleport that I can see in the Community edition. It also means it is difficult to start my own Teleport daemon, as all the ports are taken (I can configure new ones but that has a cascading effect on usage, obviously).

Is there a way to tell it to not bind to those ports? Or at least, interact with it in a way that it can be configured (e.g. adding this cluster as a trusted cluster to another Teleport set up)?

Itay, why would you want a second teleport to set up alongside a built-in one?

Sorry, that wasn’t super clear on me.

If I can configure/manage the builtin Teleport on the Gravity Community build, I am happy to do that. It was not clear how to do it though. For example, how would I add it as a Trusted Cluster to another Teleport Cluster I am running elsewhere? How would I configure the SSL certificates it’s using, and so on.

If I can’t configure/manage it, then I would prefer to have the Gravity-bundled one not running and run my own.

Does that make sense?

I think we have a special Teleport configuration resource for that. @r0mant would know more about it. Let me ping him.

On normal Teleport I’d use tctl create to create that resource, but wasn’t sure what to use with the Gravity based installation.

Itay

Hello @itay!

You’re right, in Gravity clusters Teleport is embedded into gravity-site pod which acts as an auth/proxy server for Teleport nodes which are running on cluster nodes as systemd units. Right now there is no way to disable the embedded Teleport.

As for configuration, right now Gravity provides a set of its own cluster configuration resources, all supported resources are listed here. Many of these resources are actually very similar (if not exactly the same) to their respective Teleport counterparts (such as auth connectors, roles, etc.) with some extensions, because Gravity is basically built on top of Teleport.

When it comes to configuring the embedded Teleport, Gravity does not provide direct access to the “raw” Teleport configuration file, but rather provides a resource that exposes certain configuration fields. Check out Authentication Gateway resource to see what’s currently possible.

Now, going back to your specific queries, for example to configure certificate for the cluster web UI (if that’s what you meant by “SSL certificates”), you can use TLS Key Pair resource.

Speaking of trusted clusters, Gravity provides a Trusted Cluster resource as well, however I’m not sure if will work for your use case, as its primary purpose is connecting standalone Gravity clusters to an Ops Center which is not a part of the Community Edition (I don’t think OSS version even supports this resource).

If I understood correctly, you mentioned you want to connect a bare Teleport cluster to a Gravity cluster, or vice versa. To be honest, I’m not even sure this use-case is supported - I’ve personally never tried it but it’s an interesting idea indeed.

Just thinking out loud, a Gravity cluster is just a “superset” of a Teleport cluster and is a valid Teleport cluster so technically anything you can do with Teleport you should be able to do with Gravity, including using tsh (which I know works) or tctl (which I’ve never tried) - as I mentioned above you can use gravity-site as a --proxy which is available on port 32009 on the cluster nodes.

But as I said, unfortunately this particular use-case is not officially supported/tested at the moment so while this may work, I’m not certain it won’t cause any side-effects to the Gravity-specific operations.

Thanks,
Roman

Just to add my 2 cents about running teleport along side gravity.

For me teleport seems to work fine when installed in parallel to gravity, it just requires changing the ports and the name of the binary, and does mean two instances of the node agent are running. Now I don’t run the proxy or auth service on a gravity node, but I do use the node agent because I can then use teleport to connect to the cluster to perform install/uninstall testing when a cluster isn’t present.

The config I use is basically:

root@kevin-test1:/home/knisbet/build# cat /etc/teleport.yaml
teleport:
  auth_token: <redacted>
  auth_servers:
    - 10.162.0.16:3025
ssh_service:
  enabled: yes
  listen_addr: 0.0.0.0:4022
auth_service:
  enabled: no
proxy_service:
  enabled: no

Thank you all for the extremely informative responses - I will give what @r0mant suggested a try, which is basically to configure the Gravity-bundled Teleport to user a normal Teleport cluster as a Trusted Cluster and see if it works. If it doesn’t, I’ll go the path @knisbet suggested.

FWIW, it would be nice if it was possible to control what ports Teleport binds to, which falls back to the other topic I had opened.

Unfortunately, it seems like using tctl does not work:

$ tctl -c teleport.yaml status
error: tctl must be used on the auth server

Too bad - it would be nice if did this work and I could add a normal Teleport trusted cluster.

I did try tsh login through the normal proxy at 32009:

tsh --proxy=<ip>:32009 --insecure login --user admin

This works, and I can now SSH, though it doesn’t seem like it’s setup for remote Kubernetes access - it did not download any Kubernetes configuration.