Teleport: Make configuring teleport nodes easier using teleport configure

[benarent]

Feature Request

As a follow up to https://github.com/gravitational/teleport/issues/2891, it would be helpful to have modes to teleport configure. We currently output a working example setup for proxy, auth and node.

While setting up some nodes at home, I wanted to quickly bootstrap them and having a default teleport configure --roles=node, also having a systemd unit for nodes would be super handy out of the box.

$ teleport configure

```
#
# Sample Teleport configuration file
# Creates a single proxy, auth and node server.
#
# Things to update:
#  1. ca_pin: Obtain the CA pin hash for joining more nodes by running 'tctl status'
#     on the auth server once Teleport is running.
#  2. license-if-using-teleport-enterprise.pem: If you are an Enterprise customer,
#     obtain this from https://dashboard.gravitational.com/web/
#
teleport:
nodename: teleport5auth
data_dir: /var/lib/teleport
auth_token: 6c0ef44ded8d57c07bf741ee0b2b9a8cf1def9ff8fdecbc3
auth_servers:
- 127.0.0.1:3025
log:
    output: stderr
    severity: INFO
ca_pin: sha256:ca-pin-hash-goes-here
auth_service:
enabled: "yes"
listen_addr: 0.0.0.0:3025
tokens:
- proxy,node:6c0ef44ded8d57c07bf741ee0b2b9a8cf1def9ff8fdecbc3
license_file: /path/to/license-if-using-teleport-enterprise.pem
ssh_service:
enabled: "yes"
labels:
    db_role: master
    db_type: postgres
commands:
- name: hostname
    command: [/usr/bin/hostname]
    period: 1m0s
- name: arch
    command: [/usr/bin/uname, -p]
    period: 1h0m0s
proxy_service:
enabled: "yes"
listen_addr: 0.0.0.0:3023
web_listen_addr: 0.0.0.0:3080
tunnel_listen_addr: 0.0.0.0:3024
```

$ teleport configure --roles=node

```
#
# Sample Teleport configuration file
# Setup a Teleport node.
#
# Things to update:
#  1. auth_token: Obtain this from the Teleport Auth Server
#  2. auth_location:  The FQDN/IP of the Teleport Auth server and Port. e.g. 127.0.0.1:3025
#  3. ca_pin: Obtain the CA pin hash for joining more nodes by running 'tctl status'
#     on the auth server once Teleport is running.
#  Optional:
#  4. labels: Update static and dynamic labels. 
teleport:
nodename: [auto-detect-hostname]
data_dir: /var/lib/teleport
auth_token: UPDATE_auth_token
auth_servers:
- UPDATE_auth_location:auth_port
log:
    output: stderr
    severity: INFO
ca_pin: sha256:ca-pin-hash-goes-here
auth_service:
enabled: "no"
ssh_service:
enabled: "yes"
labels:
    example_label_db_type: postgres
commands:
- name: hostname
    command: [/usr/bin/hostname]
    period: 1m0s
- name: arch
    command: [/usr/bin/uname, -p]
    period: 1h0m0s
proxy_service:
enabled: "no"
```

Motivation

For new users trying to Teleport on different machines / clusters.

Who's it for?

OSS User, Pro, Enterprise

[benarent]

@webvictim I'm really digging the new teleport configure in 4.3. Auto creating secure token is awesome and would love your input on this.

[webvictim]

Brain dump...

I'm more of a fan of deep-linking to our example systemd unit (https://github.com/gravitational/teleport/blob/master/examples/systemd/teleport.service) as it means less places we need to keep up to date.

Maybe we ought to extend/modify the output of tctl nodes add? I've always thought that we ought to provide a reference YAML config output for people to use too.

This is the current output of tctl nodes add:

The invite token: eb046479d7eae18cb793f4dde2d39fbe
This token will expire in 30 minutes

Run this on the new node to join the cluster:

> teleport start \
   --roles=node \
   --token=eb046479d7eae18cb793f4dde2d39fbe \
   --ca-pin=sha256:5abdd3a143a230fd31c9706d668bba3ee25a6e0eec54fcd69680c1ec0530fe9b \
   --auth-server=192.168.64.254:3025

Please note:

  - This invitation token will expire in 30 minutes
  - 192.168.64.254:3025 must be reachable from the new node

Maybe we could change it to something like this:

The invite token: eb046479d7eae18cb793f4dde2d39fbe
This token will expire in 30 minutes

Please note:
  - This invitation token will expire in 30 minutes
  - 192.168.64.254:3025 must be reachable from the new node

To join a node to the cluster for one-time usage, run this command:

> teleport start \
   --roles=node \
   --token=eb046479d7eae18cb793f4dde2d39fbe \
   --ca-pin=sha256:5abdd3a143a230fd31c9706d668bba3ee25a6e0eec54fcd69680c1ec0530fe9b \
   --auth-server=192.168.64.254:3025

To set up a node to join the cluster more permanently, add this configuration to /etc/teleport.yaml on the node:

teleport:
  auth_token: eb046479d7eae18cb793f4dde2d39fbe
  ca_pin: sha256:5abdd3a143a230fd31c9706d668bba3ee25a6e0eec54fcd69680c1ec0530fe9b
  auth_servers:
  - 192.168.64.254:3025
ssh_service:
  enabled: true
auth_service:
  enabled: false
proxy_service:
  enabled: false

After this:
- download the systemd unit from https://github.com/gravitational/teleport/blob/master/examples/systemd/teleport.service
- install this unit to /etc/systemd/system/teleport.service
- Run 'sudo systemctl daemon-reload' to reload systemd configuration
- Run 'sudo systemctl start teleport' to start the Teleport service
- Look at 'journalctl -u teleport' for Teleport's log output

It's all very wordy which bugs me. Maybe we could make it so that to get the bottom output, you don't run teleport start with those values, you basically change it to:

teleport configure \
  --roles=node \
  --token=eb046479d7eae18cb793f4dde2d39fbe \ 
  --ca-pin=sha256:5abdd3a143a230fd31c9706d668bba3ee25a6e0eec54fcd69680c1ec0530fe9b \
  --auth-server=192.168.64.254:3025

and then you get the YAML/systemd output with the correct values inputted instead.

A few other thoughts:

1) Maybe we'd be better off just outputting the reference YAML config with the values pre-populated, then deep-linking to a docs page which is literally just instructions on how to install Teleport with a systemd unit.
2) We could try to implement teleport install which either downloads or embeds the systemd unit and installs itself with the correct config
3) Other products which have node binaries and stuff to install that I've used in the past (like Cloudera) give you the ability to just download and run a bespoke install script on the node which will download the specified version, put the binaries in the right place, install the systemd unit, set it to auto-start etc.

• This is a bit of a smell though because it's the curl | sudo bash paradigm which is pretty bad from a security perspective.
  4) The issue we have here is that the token is only valid for joining the auth server for 30 minutes. This is kinda obvious with the teleport start methodology because it's implied that you're supposed to run it straight away, but it's less obvious that if you clear out your auth server storage in future, the node won't automatically rejoin. systemd removes the lifecycle of Teleport from the terminal that you're running in, which makes the join token expiring a bit more of an issue if you don't start it straight away so that it gets cached on disk.
  5) This is all slightly moot until we fix #2838 as well.

[benarent]

Thanks for the brain dump @webvictim , I wonder if there is a secure way to do #3? Or we can have it as an option for users starting out. I can also see us running into this UX for Teleport cloud, so the thought into it is helpful.

[awly]

If we do #3, someone will wrap that in another script. This makes our website (or github) a critical dependency on their deployment path.
Teaching teleport to generate various supervisor scripts (like systemd) and tctl to generate teleport.yaml seems a bit safer.

Also, it's good to streamline UX with systemd, of course. But I'd advise against assuming everyone runs it. It's just one possible option, not universal in the Linux world and not available on other OSs.

As for output verbosity, we could add different formats via flags, and mention them in standard output:

$ tctl nods add
The invite token: eb046479d7eae18cb793f4dde2d39fbe
This token will expire in 30 minutes

Run this on the new node to join the cluster:

> teleport start \
   --roles=node \
   --token=eb046479d7eae18cb793f4dde2d39fbe \
   --ca-pin=sha256:5abdd3a143a230fd31c9706d668bba3ee25a6e0eec54fcd69680c1ec0530fe9b \
   --auth-server=192.168.64.254:3025

To generate a systemd unit file, run this:
> tctl nodes add -o systemd

To generate a teleport.yaml for the node, run this:
> tctl nodes add -o config

To generate a Kubernetes deployment, run this:
> tctl nodes add -o k8s

To output the values as machine-readable JSON, run this:
> tctl nodes add -o json

Please note:

  - This invitation token will expire in 30 minutes
  - 192.168.64.254:3025 must be reachable from the new node

[webvictim]

I like these output flag ideas a lot. It's mostly educating people that they want to _use_ those flags which is the hard part.

[webvictim]

Also, systemd/supervisor type integration is kinda orthogonal to actually adding a node itself. I wonder whether we'd be better off implementing the output flags for YAML/k8s to make those setups easier, then improving our node setup docs considerably to link to examples for systemd/upstart/supervisord/sysvinit?

[benarent]

Yeah, +1 , I really like Andrews proposal, I provides flexibility and options for more users.