tsh: print kubernetes info in profile status

[awly]

Print when k8s support is detected, and if so what users/groups are
used.

Fixes #3447
Updates #3952

[webvictim]

I tested this locally and it works OK - it got the correct output for 2/3 clusters I had listed in tsh status. There was a Vagrant cluster which reported no Kubernetes enabled (which is correct) and a demo cluster in GKE which reported that Kubernetes was enabled and gave the correct list of kubernetes_groups.

1. There was one discrepancy - the output for my local Teleport cluster (which runs Teleport Enterprise and has a license with Kubernetes enabled, but doesn't actually have the functionality switched on in the proxy_service section of the config) reports Kubernetes: enabled but with no users/groups listed. I'm not sure why RouteToCluster is being set without Kubernetes being enabled?

teleport version: Teleport Enterprise v4.3.0git:v4.3.0-0-g73b68f4 go1.13.2

proxy_service section of the config:

proxy_service:
  enabled: yes
  ssh_public_addr: teleport.cluster:3023
  public_addr: teleport.cluster:3080
  tunnel_listen_addr: 0.0.0.0:3080
  tunnel_public_addr: teleport.cluster:3080
  https_key_file: /etc/letsencrypt/live/teleport.cluster/privkey.pem
  https_cert_file: /etc/letsencrypt/live/teleport.cluster/fullchain.pem

tsh status output:

> Profile URL:       https://teleport.cluster:3080
  Logged in as:      webvictim
  Cluster:           teleport.cluster
  Roles:             admin*
  Logins:            gus, test
  Kubernetes:        enabled
  Valid until:       2020-09-21 21:20:49 -0300 ADT [valid for 12h0m0s]
  Extensions:        permit-agent-forwarding, permit-port-forwarding, permit-pty

This probably isn't a show-stopper, but it might confuse people as to why we're reporting Kubernetes being enabled in their tsh output when they're not explicitly using it.

2. I'm wondering whether our changing the indenting/spacing of the tsh output might potentially break some automation that people have built around that? Hopefully things like cut/awk shouldn't break (and it's not good practice to parse tsh output using scripts anyway) but I figured it was worth flagging. I do know a number of customers have built automation around their usage of tsh, but I'm not sure what we can do as a mitigation.

[awly]

@webvictim I noticed the first issue too, when I re-used a Teleport cluster name:

• create cluster A with k8s enabled - RouteToCluster is set and tsh status says enabled
• create a new cluster A with k8s disabled - RouteToCluster is set and tsh status still says enabled
  Did you re-use that cluster name by chance? There could be something cached in the profile to cause this.

Regarding the second issue - good to flag it, but it seems like parsing the output in a way that depends on the exact number of spaces is doomed to fail. My hope is that the number of users parsing status output is tiny, and most of them doing it with awk or other column-oriented tools (that handle extra whitespace fine).
I think it's very unlikely to break anyone, @benarent WDYT?

[benarent]

I don't know of anyone using it.. but that likely means there is. I'll defer to @russjones, I think if we do it it should at least be in a minor release with notes.

I'm also leaning to put this into teleport status -d first, and we can come back and change the default behavior of tsh after 5.0.

[russjones]

My view is that tsh is for humans, especially if you don't use a formatting flag, so I am not against changing the formatting in this case.

[russjones]

I don't think this is not a reliable indicator that Kubernetes support is enabled. If you are using the -J flag for SSH RouteToCluster will be set. What about something like the following:

var kubeEnabled bool
if len(tlsID.KubernetesUsers) > 0 || len(tlsID.KubernetesGroups) > 0 {
   kubeEnabled = true
}

[awly]

KubernetesUsers is set to user login in the default admin role, so that's not a reliable indicator either.
I just realized that #4427 will make k8s support explicitly visible in the cert, so I'll wait for that to merge and use the new TLS extension

[russjones]

Sounds good to me.

[awly]

PTAL
Updated to use the new TLS cert extension (from #4427) to figure out when k8s support is enabled.
Also added server-side defaulting for k8s cluster name, so that tsh login without --kube-cluster still prints the right output and cluster name.