Installation

You can install kty anywhere that has access to your cluster’s API server and credentials to connect to it. The easiest way to do this is by running it on-cluster and exposing the server via a load balancer.

Configuration

Features

All the functionality is controlled via feature flags in the server:

  • pty - Dashboard when ssh happens.
  • sftp - Enables scp and sftp.
  • ingress-tunnel - Provides ssh -L forwarding from a local port to the cluster.
  • egress-tunnel - Provides ssh -R forwarding from the cluster to a local port.

Bring Your Own Provider

By default, kty provides Github and Google authentication via. auth0. To get your own setup using auth0, check out their instructions.

You can, alternatively, use your own provider. It must support the device code flow and have a URL that has the openid configuration. Take a look at the configuration for kty serve for the required values.

On-Cluster

Check out the helm chart for an easy way to get started. If not using helm, there are some things to be aware of:

  • Credentials need to be mounted into the pod, see Server RBAC for a minimal list of permissions.
  • You need the pod to be reachable from where you’re running ssh. This can be done by any TCP load balancer. If you’re running in the cloud, setting the server’s service to type: LoadBalancer is the easiest. Alternatives include using the gateway api or configuring your ingress controller to route TCP.

If you’re debugging something, instead of setting global verbosity with -vv, use RUST_LOG=none,kty=debug. That’ll keep other crates that are especially noisy out of the output.

Off-Cluster

If you’re already using jump hosts to get into your cluster, kty can run there as well. Here are some things to be aware of:

  • Provide credentials by creating a kubeconfig that uses the correct service account. here are some plugins to make this easy. You’ll still need a valid ClusterRole and ClusterRoleBinding setup. Take a look at the sample rbac to see what do to there.
  • For ingress-tunnel support, you’ll need to have the server running on a network that can reach IP addresses in the cluster (nodes, pods) and can resolve cluster DNS.
  • For egress-tunnel support, you’ll need to have the server itself reachable from any pod in the cluster. In addition, make sure to configure --pod-name, --pod-uid and --pod-ip to some real values in the serve command.

Server RBAC

The kty server needs to be able to:

  • Impersonate users and groups.
  • Manage keys.
  • Optionally update the CRDs.

To do the minimum of this, you can use the following ClusterRole. For a more in-depth example, take a look at the helm config.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: impersonator
rules:
  - apiGroups: ['']
    resources:
      - users
      - groups
    verbs:
      - impersonate
    # Restrict the groups/users that can be impersonated through kty.
    # resourceNames:
    #   - foo@bar.com
    #   - my_group
Access ControlHelm