feat(network): add egress tunneling

- Enabled `ssh -R` for tunneling from the cluster
  to the local host. This introduces a bunch of
  weirdness around "how does the cluster contact
  the server".
- Moved `stream` to `tunnel` and `direct` to
  `ingress`. This is closer to what it is actually
  doing, especially because I didn't understand
  the difference between direct/forward/tcpip.
- Added feature flags. Now, what features are
  enabled can be configured at runtime. This
  allows any incoming requests to be
  short-circuited if they'd never work or
  shouldn't be supported.
- Made `Authenticate` return an identity (that has
  been authenticated) instead of a client. It is
  weird to have `Identity::authenticate` return an
  identity, but it makes more sense for `Key`.
- Moved `Identity` into `State::Authenticated`.
  This was primarily to get the user's identity on
  the created `Egress` tunnel but likely makes
  more sense anyways as you end up creating a new
  client all the time as it is. Unfortunately, the
  `Controller` is still required to create that
  client - they can't be minted fresh from an
  Identity.

Author: grampelberg

Cargo.lock

@@ -46,6 +46,7 @@ jsonwebtoken = "9.3.0"
 k8s-openapi = { version = "0.22.0", features = ["earliest"] }
 kube = { version = "0.93.1", features = ["derive", "runtime", "ws"] }
 lazy_static = "1.5.0"
+local-ip-address = "0.6.2"
 mio = "1.0.2"
 pkcs8 = "0.10.2"
 prometheus = "0.13.4"
@@ -67,6 +68,7 @@ serde_json = "1.0.127"
 serde_path_to_error = "0.1.16"
 serde_yaml = "0.9.34"
 ssh-key = "0.6.6"
+strum = { version = "0.26.3", features = ["derive"] }
 strum_macros = "0.26.4"
 syntect = "5.2.0"
 syntect-tui = "3.0.3"

Cargo.toml

@@ -42,7 +42,7 @@ be available to run inside the cluster.
 
 [k3d]: https://k3d.io/v5.6.3/#releases
 
-## Forwarding
+## Ingress Tunnel
 
 If testing port forwarding and running the service locally (aka not on the
 cluster), you won't have access to any of the DNS or IP addresses that might be
@@ -60,3 +60,14 @@ ssh -L 9090:svc/default/localhost:9091 me@localhost -p 2222
 
 Testing `pods` and `nodes` requires running on the cluster as the response from
 `addr` for those is IP addresses.
+
+## Egress Tunnel
+
+If you're not running on the cluster, you'll want to:
+
+- Make sure you're running from the same network (doable with some games with
+  VPNs and local clusters).
+- Set `HOSTNAME` to a pod in the cluster that is in your default namespace.
+- Set `POD_UID` to the `metadata.uid` of the pod from `HOSTNAME`.
+- Set `POD_IP` to the IP address of your host. You can get this by going into a
+  pod and doing a `nslookup host.docker.internal`.

DEVELOPMENT.md

@@ -12,7 +12,8 @@ You can:
 - Access the logs for running and exited containers in a pod.
 - Forward a local port remotely, allowing access to services and pods in the
   cluster.
-  - `scp` files from pods. sftp clients work as well.
+- Forward a remote service to your local system.
+- `scp` files from pods. sftp clients work as well.
 
 ![demo](./assets/demo.gif)
 
@@ -77,7 +78,7 @@ ssh anything@my-remote-host-or-ip -p 2222
 The provided username is not used as your identity is authenticated via other
 mechanisms.
 
-### Port Forward
+### Ingress Tunnel (`ssh -L`)
 
 You can forward requests from a local port into a resource on the remote
 cluster. The supported resources are `nodes`, `pods` and `services`. See the
@@ -108,6 +109,19 @@ With that running in one terminal, you can run this in another:
 ssh my-node-username@localhost -p 3333
 ```
 
+### Egress Tunnel (`ssh -R`)
+
+You can forward a remote service on your cluster to a port on your local host.
+
+To forward port 8080 on service `default/kuberift` to port `9090` on your local
+system, you can run:
+
+```bash
+ssh me@my-cluster -p 2222 -R default/kuberift:8080:localhost:9090
+```
+
+The format for service definitions is `<namespace>/<service-name>`.
+
 ### SFTP
 
 The cluster is represented by a file tree:

README.md

@@ -1,5 +1,10 @@
 # TODO
 
+## Documentation
+
+- Get a full architecture explanation together.
+- Explain "how it works" for each piece of functionality.
+
 ## Authorization
 
 - Groups are probably what most users are going to want to use to configure all
@@ -49,6 +54,14 @@
 - Enable `ssh -L` for forwarding requests _into_ a pod.
 - Enable `ssh -R` for forwarding a remote service _into_ a localhost.
 
-## TCP/IP Forwarding
+## Ingress Tunnel
+
+## Egress Tunnel
+
+- Display error for when the `tcpip_forward` address is `localhost`.
+- Need some way to do cleanup and lifecycle management of endpoints and
+  services.
+
+## Build
 
-- Implement `-R` for proxying from the cluster to localhost.
+- Move client_id and config_url to a build-time concern.

TODO.md

@@ -45,7 +45,7 @@ kubectl create clusterrolebinding foo-bar-com --clusterrole=<my-role> --user=foo
 Note that you can use a `RoleBinding` instead, but only for specific
 functionality.
 
-### SSH RBAC
+### SSH
 
 The minimum permissions are:
 
@@ -71,7 +71,7 @@ verbs: ['create']
 Note: without the full permissions it is possible that the dashboard has some
 issues rendering.
 
-### Port Forwarding RBAC
+### Ingress Tunnel (`ssh -L`)
 
 For each supported resource type (nodes, services, pods), you need:
 
@@ -106,7 +106,16 @@ rules:
       - get
 ```
 
-### SFTP(SCP) RBAC
+### Egress Tunnel (`ssh -L`)
+
+The minimum permissions are:
+
+```yaml
+resources: ['services', 'endpointslices']
+verbs: ['patch']
+```
+
+### SFTP(SCP)
 
 To support `scp`, the minimum permissions are:
 

docs/auth.md

@@ -3,26 +3,55 @@
 The `kuberift` server needs access to your cluster's API server and credentials
 to connect to it. There are a couple ways to do this:
 
-- On cluster - you can run it on cluster. Check out the [helm chart][helm-chart]
-  for an easy way to get started. By running it on cluster, you get access and
-  credentials automatically. The server then needs to be exposed so that you can
-  connect to it. 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][gateway-api] or
-  configuring your ingress controller to route TCP.
-- Off cluster - if you're already using jump hosts to get into your cluster,
-  kuberift can run there. All you need to do is create a `kubeconfig` that uses
-  the correct service account. There are [some plugins][sa-plugin] to make this
-  easy. You'll still need a valid `ClusterRole` and `ClusterRoleBinding` setup.
-  Take a look at the sample [rbac][helm-rbac] to see what do to there.
+- [On cluster](#on-cluster)
+- [Off cluster](#off-cluster)
 
 [gateway-api]: https://gateway-api.sigs.k8s.io
 [helm-chart]: #helm
 [sa-plugin]:
   https://github.com/superbrothers/kubectl-view-serviceaccount-kubeconfig-plugin
 [helm-rbac]: helm/templates/rbac.yaml
 
-## Helm
+## 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, kuberift provides Github and Google authentication via.
+[auth0][auth0]. To get your own setup using auth0, check out their
+[instructions][auth0-setup].
+
+You can, alternatively, use your own provider. It must support the [device
+code][device-code] flow and have a URL that has the openid configuration. Take a
+look at the configuration for `kuberift serve` for the required values.
+
+[auth0]: https://auth0.com
+[auth0-setup]:
+  https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow/call-your-api-using-the-device-authorization-flow#prerequisites
+[device-code]: https://www.oauth.com/oauth2-servers/device-flow/
+
+## On-Cluster
+
+Check out the [helm chart][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](#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][gateway-api] or configuring your ingress controller to
+  route TCP.
+
+### Helm
 
 There is a provided `getting-started.yaml` set of values. To install this on
 your cluster, you can run:
@@ -45,20 +74,21 @@ For more detailed instructions, take a look at the [README][helm-readme].
 
 [helm-readme]: helm/README.md
 
-## Bring Your Own Provider
+## Off-Cluster
 
-By default, kuberift provides Github and Google authentication via.
-[auth0][auth0]. To get your own setup using auth0, check out their
-[instructions][auth0-setup].
+If you're already using jump hosts to get into your cluster, kuberift can run
+there. Here are some things to be aware of:
 
-You can, alternatively, use your own provider. It must support the [device
-code][device-code] flow and have a URL that has the openid configuration. Take a
-look at the configuration for `kuberift serve` for the required values.
-
-[auth0]: https://auth0.com
-[auth0-setup]:
-  https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow/call-your-api-using-the-device-authorization-flow#prerequisites
-[device-code]: https://www.oauth.com/oauth2-servers/device-flow/
+- Provide credentials by creating a `kubeconfig` that uses the correct service
+  account. here are [some plugins][sa-plugin] to make this easy. You'll still
+  need a valid `ClusterRole` and `ClusterRoleBinding` setup. Take a look at the
+  sample [rbac][helm-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
 
@@ -68,38 +98,23 @@ The kuberift server needs to be able to:
 - Manage `keys`.
 - Optionally update the CRDs.
 
-To do the minimum of this, you can use the following `ClusterRole` + `Role`. For
-a more in-depth example, take a look at the
-[helm config](helm/templates/rbac.yaml).
+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](helm/templates/rbac.yaml).
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
 name: impersonator
 rules:
-  - apiGroups:
-      - ''
+  - apiGroups: ['']
     resources:
       - users
       - groups
     verbs:
-      - 'impersonate'
+      - impersonate
     # Restrict the groups/users that can be impersonated through kuberift.
     # resourceNames:
     #   - foo@bar.com
     #   - my_group
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: Role
-metadata:
-name: kuberift
-rules:
-  - apiGroups:
-      - 'key.kuberift.com'
-    resources:
-      - keys
-    verbs:
-      - '*'
----
 ```

docs/deployment.md

@@ -96,6 +96,10 @@ spec:
               value: {{ .clientID }}
             - name: KUBERIFT_OID_CONFIG_URL
               value: {{ .configURL }}
+            - name: POD_UID
+              valueFrom:
+                fieldRef:
+                  fieldPath: metadata.uid
           {{- end }}
 
           {{- if .resources}}